The Fat Man Manifesto

May 7, 2012

Recently I was at a conference where people were decrying the fact that many folks didn’t even know what the values and principles of the Agile Manifesto were. Unfortunately this led to yet another round of Agile Navel Gazing (ANG) as we flogged ourselves with the 12 principles. I’ve started to feel like we in the Agile community have started to treat the Manifesto as some sort of stone tablets that must be worshipped rather than questioned. In fact, I’m starting to feel like maybe it’s time for a new manifesto. So I thought I would give it a spin myself and see what I could come up with. Hence the birth of the “Fat Man Manifesto”

The Fat Man Manifesto

We value:

  • People eating together over eating at their desks alone
  • People celebrating their work over adherence to process
  • People sharing over isolation

The Fat Man Principles

  1. Food in every meeting
  2. Barbecue often
  3. Lots of snacks
  4. Drink beer
  5. Party competitively
  6. Eat lunch with your team
  7. Carpool
  8. Music Always

The Fat Man Framework

So there you have it. A new manifesto for people who appreciate good food and good company. Would this manifesto work any better for teams than the Agile Manifesto? Who knows? I’d be willing to try it out.

The fact is that there is nothing really inherently special about writing a manifesto. I’ll tell you a secret: it’s really easy. Anybody can do it. In fact, I think everybody should give it a try! Writing a manifesto is fun, and it gets you thinking about what you really value about the people and the work that you do together. I think there should be a proliferation of manifestos. The Fat Man Manifesto is mine, and I even got some signatories!

So what about your manifesto? What kind of manifesto would you write?

 


The Stance of Readiness for Change

May 5, 2012

I think this whole “Welcome changing requirements, even late in development” thing is a lot more challenging that I had first anticipated. It was a long week, and perhaps not my best. I pushed myself hard at work and at home. Probably too hard. Soon I discovered that much to my chagrin, it is really difficult to be receptive to changing requirements when you are exhausted. Where is the principle in the manifesto that covers sustainable pace? Oh nuts…that one doesn’t come until week eight! I’m never going to last that long!

Well, while I reconsider the wisdom of this little exercise, I wanted to share one more observation: All this thinking and writing about the manifesto has me writing software again. I guess if you talk about it long enough it’s bound to happen sooner or later. So now I have a small integration project that I’m doing for some folks at work. I gave a little demo and asked for some feedback. Guess what I got? That’s right: no requirements changes. I think those hosers are going to wait until the last minute to hit me with the changes! I suppose to some degree that is a natural consequence of the way software tends to evolve.

This all reminds me of Brian Marick’s excellent “Agile Stance” talk that he gave at XP2011. He compared agility to ballroom dancing. As he put it, we are all in a partnership with our customers as if we are engaged in a dance where each party may not know exactly what the next move is. This leads to a posture or stance of readiness. We stand on the balls of our feet, we notice the way our partner is leaning, we are looking for the signals that will indicate what the next move should be and thinking about how we react. I think it is a very “present” and alive way of being – and it’s where we need to be in order to be ready to respond to our customer’s changes late in the game.


Welcome Changing Requirements, Even If You Don’t Want To

April 30, 2012

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Agile Manifesto, 2nd Principle

I have a confession to make: I find this particular principle hard to live up to. Let’s just face it: I don’t like surprises.

This week I’m going to try and live this principle. It turns out my kids are going to put this to the test almost immediately. We’re  getting ready for school this morning and the pre-schooler is off to a slow start. “Hey honey, can you take care of kid 2.0 while I take kid 1.0 to school?” Right off the bat I have a requirement that’s changed. Good grief!

Welcome changing requirements. So, I put on my patented Agile Smile and say, “Sure honey, no problem!”

The thing that makes last minute requirements changes tough is that you are usually so close to your goal when it happens. There I am: mentally I’ve got my coat on and one foot out the door headed to work (my goal). Here is a last minute request, a delay of game. A request for help. There is no question that I’m helping out my family by accepting this last minute request. However, it isn’t without some compromise (My own ability to get to the office in reasonable time). I think I’m juggling the needs of multiple customers in this case. Some days I do it well, other days…not so much.

One thought that occurs to me is that you have to have your customer clearly in mind (which I obviously don’t). Juggling multiple customers makes it really hard to manage changing requirements. It must suck to be product owner sometimes. The more I look at this principle, the more I want to re-write it:

“Welcome changing requirements, even if you don’t want to. Agile processes harness you to the customer’s every whim.”

And that’s probably a good thing. I think it’s going to be a long week…


Delivering Value With The Kids

April 27, 2012
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
1st principle, Agile Manifesto

No, I’m not selling the kids to the circus…yet. Actually, my wife is out of town, so I get the kids for the weekend. Aside from making it the usual “Dad weekend” with all the pizza and cake you can eat, I’ve been trying to think of some ways to share this whole “delivering value” lesson with them. Here are a few ideas I’ve come up with:

  1. Teach the children to cheat on their math homework using the Ruby interpreter
  2. Teach kids to play blackjack or 5 card stud
  3. Take kids to the horse races and show them how to place a bet
  4. Have them make my stock picks – if the numbers are up, they get desert

They are going to have a blast! I’m just getting started. It’s going to be  great weekend!

Of course what I’m doing is playing with the idea of value. Are there bad values? Is there value that we deliver that has a negative effect on our customers? How does that affect our ability to deliver?


Feeding the Value Machine

April 26, 2012

In my effort to explore living the first principle of the Agile Manifesto this week I have found myself asking the question, “How can I provide value for you?” Of course that presumes I have something useful to offer. So if I take a brief inventory of useful or valuable stuff I know, here is what I come up with:

  • Software Development knowledge & experience (programming, practices, etc.)
  • Team building (facilitation, training, negotiation, games, & other soft skills)
  • Sailing knowledge & experience
  • Boat building
  • Wood working
  • etc.

All of it has some component of knowledge and learning associated with it. I had an interest in these things and took the time to learn more about these topics and perhaps more importantly gain experience with the subjects I was passionate about. Could it be that this is the pool of value that I have to offer? If so, then an important activity here is growing that pool of useful knowledge, experience (or value). It doesn’t just happen by itself. We have to make a conscious investment in these activities in order to improve our knowledge (and the corresponding value proposition).

That means that not only do I need to  be asking how I can add value, but I also need to invest some of my time investing in growing or maturing the value that I’m able to provide. If we take a look at the first principle from the Manifesto Again:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Let’s face it, continuously providing value is a daunting task. It seems almost impossible at the individual level. Part of providing that value is going to be continuously nurturing the capability within ourselves. How can we do that?

  • Read books
  • Get out there and try out our ideas (experience)
  • Share the ideas with others
  • Expand the variety of activities we engage in

All of these actions will help to nurture the value that you may offer. In order to be providing lots of value you need to “feed the machine” and seek ways to improve or grow the value that you offer.


Shut Up and Focus

April 25, 2012

So I learned a few more things about creating value today, especially with regard to creating value with training.

First, as a trainer I’m not always creating value when I’m talking. In fact, I may actually be discouraging much more valuable input from someone else by dominating the conversation myself. So sometimes there is more value in knowing when to shut up and listen.

Shutting up is hard for me, not only because I simply adore the sound of my own voice (Me, me, me!), but also because the people attending the training want you to give them the answer. When you ask a question and then clam up, the increase in pressure in the room is almost tangible. Of course the real value in the training is when they come to a realization on their own. Then they are much more likely to retain that knowledge. That means you have to be able to ask them to work out the problem without you telling them the answer. It sounds trivial, but it can be excruciating to live in those anxious moments of silence that exist between the end of the question and the first tentative answer.

Summary: there is value in silence.

Second, focus enhances value. So today we used a timer when we did our training. The two of us each had a seven minute time limit on any given topic before we had to hand off to the other trainer. We kept this up for nearly eight hours (with some breaks). Having a deadline serves to focus the mind and accelerate the delivery of value. We were right on topic and right on time all day long. Whereas the previous day we had tended to drift off topic occasionally, now we were much more focused on making point, sharing an idea or delivering an exercise.

Another benefit of the short timeframe (also related to focus) was that we didn’t have much time to drift or daydream. You got seven minutes off while the other trainer was working with the class, but you had better be paying attention, because you were guaranteed to be back in the hot seat in just a couple of minutes. There was no time for distractions. The overall feedback from the class was that they liked the change.

Summary: focus enhances value.

Finally, we added a “yellow card” system where the members of the class could flag a topic as dragging on too long or less useful. This gave them a way to give us feedback about the value that they were getting out of the class in real time.

Summary: continuous delivery of value works best when there is a mechanism for feedback from the customer.


Value Creation is a Dialog

April 25, 2012

Day two of trying to live the first principle of the 12 principles of the Agile Manifesto (“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”). So far so good. I spent much of the day co-training a class. It was a unique training because we asked the attendees to pick the topics that were most valuable to them, prioritize them, then taught the material. Finally we finished up with periodic retrospectives throughout the day. It seemed fairly obvious that this was a great example of asking the customer what they value, delivering the value, then checking to see if they thought it was really useful. After an entire rather exhausting day of this, it occurs to me that continuously providing value is actually a dialog (or perhaps an ongoing experiment) that works like this

  1. Ask what value you can provide
  2. Attempt to provide that value
  3. Ask the customer if they got the expected value
  4. Adjust and repeat

I think that value cycle lies at the heart of a lot of Agile processes. You see this in the sprint reviews and retrospectives on projects. It really is the PDCA cycle all over again. But speaking for myself, I think I’m going to have to modify my approach this week. Here’s a sample:

  • Ask friend: How can I provide value
  • Friend: Buy me a beer
  • Beer provided
  • Ask friend: So, how’s that beer?
  • Friend: Excellent! Too warm! Too foamy! bitter, etc.

Value delivered.