Agile Coaching and Training is a Scam

In the Agile world, coaches and trainers are distinctions that were created in order to create different ways of making money. They have no useful business purpose outside of filling the pockets of consultants with cash.

How can I maintain this? Here’s how I see it now: I (used to) have friends who are trainers. They are normal people like you and me. They typically got their start as project managers and or scrum masters just like the rest of us. At some point they go through a process where they are vetted for the following:

1) An understanding of the vague terms used in the agile lexicon
2) Conformance to religiously held views regarding a process
3) Communication skills & attitude

Once they are hit with the golden hammer, anointed by the powers that be, given the blessings of the bishops, or certified, they can charge large amounts of money to provide the same training over and over…and over…

Or they can just go out on their own and do it without any such approval. Of course if they do that, then they have to survive based on whatever actual skills they may have. They have to come up with their own material that isn’t provided by some governing authority. They have to market their skills all by themselves, and it’s a cold and unforgiving consulting market out there.

Regardless of which path you choose to take, are you doing anything that a good scrum master or a project manager couldn’t do? No. Training is part of any good manager’s role. Many scrum masters that I know have actually given CSM training at one time or another – and done quite well. Furthermore, the agile training that I’ve seen isn’t rocket science. It takes only marginal presentation skills to successfully deliver agile training. It’s not original material. It’s not like you have to know how to write code. In fact, most trainers I know, can’t write code. Are these really the people who are going to tell software developers how to work?

It’s nice work if you can get it.

Impediment Spotting

So there I was in a meeting the other day (saving the world…yawn). Everything was going smoothly (too smoothly) so I did a quick spot check for impediments. You know, “Hey folks, before we wrap things up, are there any blockers we should be aware of?” There was the usual pregnant pause and then:

• “The teams aren’t talking to each other. I think we should have a wiki page to share what we are doing.”
• “We need a common defect tracking system. I have to look in too many places to find bugs.”
• “We don’t do test driven development.”
• “Bob’s not helping.”

Oh brother…Me and my big mouth. Where to start? One of the first things that I often encounter when soliciting impediments is the dreaded vague problem statement. Some aren’t even impediments at all. They’re just statements of opinion. Let’s take the TDD one as an example:

“We don’t do test driven development.”

Really? No kidding? That’s too bad. Why should I care? Seriously, I know TDD is supposed to be good for you (like motherhood and apple pie), but why should I care if we are doing TDD or not? Why is not doing TDD a problem? Do the teams do any unit testing? Do they have a high defect rate? Is there a lot of staff turnover? Now where did I leave my tiny little violin?

Let’s pretend for the moment that the problem gets a little further refinement:

“We can’t quickly validate our code and spend hours in debugging. We should do test driven development.”

Ah, I see…that’s a little better. Now I think I understand your problem. You’ve even gone so far as to offer a solution (how thoughtful). In fact, what we’ve done is mix up the problem statement and the solution. Ugh! In one fell swoop we have managed to describe the problem and eliminate a whole world of potential solutions from consideration. Brilliant! How about we just limit ourselves to the problem for now, shall we?

“We can’t quickly validate our code and spend hours in debugging.”

Now THIS is a problem statement (OK…impediment) I can work with. I know who is affected. I know what they are doing, I know why it’s a problem. I know where they end up. There’s a lot of information here. So now that we have a decent statement of our impediment, what do we do about it?

Well, you have a couple of options:

1. Do some root cause analysis (dig into that impediment and find out what’s going on)
2. Skip the root cause analysis, because you already know the answer. (No, I’m serious, why screw around? When you know, you know – you know?)

From there we brainstorm a few potential solutions and then we are off to the PDCA races!

You can get all of this from a crappy problem statement. Well, actually you can’t. That’s why you need to take the time to refine the problem statement. Notice that I didn’t just throw out the impediment in disgust in the very beginning. Sometimes an impediment is a clue and we end up the detectives.

Happy sleuthing!

Announcing: The Little Book of Impediments

Impediments have long been a topic that is near and dear to my heart. I’ve just published the first draft of a book dedicated to managing impediments on Leanpub. It’s an idea that I’ve been thinking about for years and finally decided to execute on. The book is a collection of many of my ideas on dealing with impediments from this blog, as well as from presentations and tutuorials that I have done at many conferences. There is still a long way to go, but if you are interested, you can get an advance copy from Leanpub (https://leanpub.com/ImpedimentsBook). You can also provide comments and get updates on twitter using the hashtag #impedimentsbook

Slowing Down: Actions

In my last post, I summarized a talk, Slowing Down, that I had facilitated recently at Agile Open Northwest.  There was a fair amount of interest in the topic and some folks mentioned that I should do a follow on session focused on specific things we could do to start slowing down. It was a call to action. Once again, I walked into the session with very little idea of what would happen and how it would all work out.

The Session

The session got off to a bit of a funny start. I started by giving an introduction to the session, and creating some posters, and taping them up, and balancing my first cup of coffee for the morning – all at the same time. Yes, you got it – I was a multi-tasking madman! Of course I promptly tipped my precious coffee into the box of supplies, thereby destroying the supplies for the session and depriving myself of the coffee I so desperately needed. I couldn’t have put together a better demonstration of attempting too much if I had tried. After that little disaster, I slowed down a bit. We decided to put together two lists: Things to start, and things to stop. Here is what we came up with (in no particular order):

Things to Start

• Ignoring email
• Make a list and then throw it away
• Doodle
• Completing actions
• Schedule empty space
• Intentionally doing nothing
• Reducing my WIP
• Turn off email for 1-2 hours per day
• Using Pomodoro more regularly
• Get a dog
• Draw a picture
• Gratitude
• Listening to music each day
• Exercise – setup yoga with group or something else with coworkers
• Start reading more about Agile
• Observe my thoughts without judgement
• Start acting like a toddler
• Reading for fun
• Walking slow
• Notice my breath and how it feels
• Eating lunch NOT at your desk
• Watching grass grow
• Amble
• Phone stacking at lunches and dinners and meetings
• Being present
• Watch waves roll in
• Saying single sentences only
• Finishing things
• Reward slow actions

Things to stop

• Stop carrying laptop
• Stop reading more than 2 paragraphs
• Stop burying the lead in emails
• Multi-tasking
• Don’t go to Agile 2013
• Stop reading everything related to the next meeting’s topic. Be prepared to be unprepared.
• Stop working through the 12:00 hour and go for a walk
• Stop waiting for permission to initiate change
• TV
• Stop reading everything all the time
• Stop solving problems without asking 3 questions first
• Stop trying to fill the void of silence first
• Stop avoiding nagging release issues
• Stop checking email on my phone every time I have a spare moment
• Stop checking email before I go to sleep
• Remember there is always tomorrow…
• Stop checking IM’s the instant that they arrive
• When I’m at a conference, stop going to every session. Take time out each day to just go outside
• Stop having talks longer than 25 minutes
• Stop bringing anything on a trip that I didn’t use last time
• Ditch watch
• Drive less
• Turn off email
• Work less by taking a 3 week vacation
• Imitrex

Recommended books

• Personal Kanban
• The Tao of Pooh
• The Shibumi Strategy
• The Tao Te Ching
• Pomodoro Illustrated

Obviously we captured a lot of “stuff” here. Some of it I really like, and other things I will probably never try. I’m committed to trying many of them. I’m still absorbing, so for now I’ll take it one day at a time. Once again, I’m grateful to those who participated in the session. I hope some of these ideas serve as a starting point for others in the same fashion they have for me.

Slowing Down

Last week I led a session at Agile Open Northwest called, “Slowing Down”. The idea for this session was inspired by my own struggles with becoming quite over-committed to a variety of things (my job, my hobbies, etc.) and the resulting stress and crisis it has created for me. You see, the funny thing about it all was that even though I was perfectly aware of what I was doing by over-committing like crazy, I couldn’t seem to stop.

The Introduction

So I came to this session, not as an expert selling a solution, but rather as a novice seeking help. Since I really didn’t know where things were going to go, I simply started with the session title. I wrote “Slowing Down” on the whiteboard and introduced myself to the small group of people who had joined me for the session. I started with a story of my own. It was a bit like what I imagine an Alcholics Anonymous conversation starts like, “Hi, my name is Tom and I can’t slow down…”

Fortunately for me, many in the audience had a similar story. Since we are a bunch of software development types, it didn’t take long for the concept of sustainable pace to be mentioned. Of course we all knew full well what sustainable pace means. It is a term that I originally encountered in Xtreme Programming. I could ramble on for hours about the importance of keeping the pace and duration of your work under control so that you can sustain your creative energy and not burn out. Easy. But I can’t seem to do it worth a damn. That’s the interesting bit. Why? Why is it that, even knowing the importance of maintaining a sustainable pace, I and others like me seem to struggle so hard with it?

Why?

A few interesting ideas for why we get sucked into this dynamic were suggested during the session:

Ownership – Feelings of ownership can make it hard for people to let go of tasks and delegate them to others. For example, it is very easy for project leaders to feel a very strong sense of ownership and commitment to the success of projects that they are working on. This can be quite normal – often our organization want this kind of commitment from us. However, like many things, this can go too far. The undesired dynamic plays out as a feeling that you and only you are personally responsible for the success or failure of the project (what happened to the team?). When challenged, people who struggle with ownership issues will often look with incomprehension when asked to give up some part of a project, “If I don’t do it, who will?” I think that in some cases this inability to give up ownership can also manifest as heroism (ownership + adrenaline junkie). Perhaps at its heart, ownership issues are tightly tied to ego. They seem to manifest as a very selfish view of project success or failure.

Bad Habit

Habit – We form all sorts of bad habits that contribute to the stress in our lives. For example, I’ve gotten into the habit of checking my email compulsively throughout the day. Often even when at home. Habits like this that tether us to the office and constant communication serve to raise our overall stress levels. Other examples include habitually taking home the laptop with you every night and carrying the work phone with you wherever you go.

Culture – One major reason for difficulty with slowing down is the work culture you live in. People shared many different stories of how the expectations at work made it hard or almost impossible for them to escape the pressures of the office. Everything from evil bosses that demand attendance over performance to co-workers who make snide comments when a colleague dares to leave the office at 5:00. Some places even provide rewards for those who make decisions that put work above any other activity. Examples of these sorts of influences in the workplace abound.

All of these influences are very common reasons why people find it hard to slow down. It is no wonder that there are many who struggle to maintain a sustainable pace of work at the office. Understanding why you are feeling that pressure is critical to understanding what strategies to use to manage the problem. The strategies where where we ended up going next.

Strategies

As we moved along in our discussion, people identified strategies that could be used to deal with slowing down and establishing a more sustainable pace. We captured and expanded upon those strategies as we wove the narrative of slowing down.

Setting Boundaries

The first strategy that came up was setting boundaries. Setting boundaries is fundamental to establishing control over your own schedule and pace. Fail to do this and all the rest really doesn’t matter. People told many stories about how they managed to establish meaningful boundaries in their work lives that helped them to keep a meaningful sustainable pace. Some made their 9 to 5 work hours non-negotiable. They never offered the longer hours that many fall into. You get me for 8 hours a day, and the rest of my life is not for sale. It was remarkable to hear the strength of some of these voices. Others refused to take work home or turned off the cell phone after 5.

Basically, what I heard were people establishing a service level agreement for their participation. One benefit that I noticed from this sort of boundary was that it made visible to everyone just what they could and could not expect from you. Visibility is a strongly held value in the agile community and it struck me that making my boundaries more visible would be a uniquely agile way of dealing with the issue (I’m closing the door now…). Another way of making my boundaries and limits visible would be to use a personal task board mechanism like personal kanban in order to not only make my existing commitments visible, but also to review them myself and keep tabs on how the work load is balanced (or not).

Reflections

Diana Larsen did a great session last year at Agile2012 on personal retrospectives. As team facilitators, we are pretty well versed in running team retrospectives, however I never do them by myself. That is exactly what Diana proposed: do self-retrospectives on a periodic basis in order to reflect on your progress toward your goals, and where you want to go next. I think this would be a useful tool for many, whether it is only at the end of the year or much more frequently. I know that my own responsibilities feel like they have changed quite dramatically in the last year. Stopping to assess those changes might just give you the opportunity to recognize stressful trends and start to do something about it. You can start to do it now, or wait until a crisis imposes that reflection. Your call.

This is just my summary of what I saw and heard during our talk. Looking at the sheer number of topics that we covered it’s quite apparent to me that we covered a broad number of subjects. Many of them are worthy of deep investigation. Perhaps, as the mind map suggests, we have created a map of the terrain of the topic of slowing down. Others may have different take aways. I certainly hope so. I appreciated everything that the group brought to the conversation and I hope that I was able to serve as a reasonable scribe for what was said.

Be Like Beaker: Experiment on Yourself

“Bunsen Honeydew here at Muppet Labs where the future is being made today.”

As a kid, as soon as I heard those words from the good professor I just knew that something awful was going to happen to his poor hapless assistant, Beaker. Beaker knew it too, that was the really hilarious part about this Muppets skit. His pitiful, terrified protestations to whatever sadly misinformed experiment the professor was going to inflict on him kept me rolling on the floor laughing. Being able to see the inevitable outcome a mile off just made it even funnier. You could see it, Beaker could see it, and Honeydew didn’t have the faintest clue.

Even as an adult, watching Beaker on the Muppets makes me laugh so hard I avoid milk for fear of being caught spraying it out of my nose.

Of course that’s why you have a trusty lab assistant isn’t it? You need somebody to experiment on, right? When you have a truly brilliant hypothesis – we’re talking real genius here, what you really need is a willing subject to perform your tests on. What could possibly go wrong? After all, how else do we expect science to progress? I’ve seen a lot of Bunsen Honeydews in software development. Shucks, I’ve played one myself. For 50 cents and a cup of coffee I’ll teach you how to be a Honeydew too.

Unfortunately, for almost every professor Honeydew there is a corresponding poor schmuck playing the role of Beaker. Maybe it’s just one person or maybe its a whole team (If you’ve ever experimented on an entire team, you are hereby entitled to call yourself an “agile coach”). Sometimes it seems as though every lead, manager and coach has to go through a Honeydew phase, blindly inflicting their experiments on others.

Let’s face it: having your very own lab assistant to experiment on is great if you can manage it (you lucky dog). But what do you do if you don’t have a Beaker handy – or the wily creature keeps running away. What then? Well there is still one test subject available: You.

Yeah, you.

“What? No!” I can hear you exclaim. Who in their right mind would experiment on themselves? Well, as it turns out, there is a rather curious and rich history of the famous and infamous who have performed experiments on themselves. And we’re not talking about trivial stuff here either. Many of these experiments represent real and substantive contributions to the body of scientific knowledge.

Benjamin Franklin is an early example of someone who performed self-experiments. He tracked how well he was able to dedicate his full attention to the “Thirteen Virtues” for an entire week. Anybody want to try to dedicate their attention to the 12 Principles of the Agile Manifesto for a week? I tried once and learned some very interesting things about myself and the manifesto.

Another example, Dr. Albert Hoffman accidentally discovered the psychedelic properties  of LSD and then subsequently experimented with it on himself. Wow! Me too!

Of course fiction is full of less fortunate examples of self experimentation. Take for example, the tale of Dr. Jekyll and Mr. Hyde or The Invisible Man. One hopes we are not so unfortunate in our own efforts!

One of my professors in college was an advocate of self experimentation. He tried sleeping each night with the head of his bed tilted toward the ground so that the blood would pool in his head as he slept. He reports that it gave him a tremendous headache.

You might laugh at that last example, but it highlights a very important point that I want to make: When you test out ideas on yourself, you can get rapid feedback on what may pay off and what won’t – all without inconveniencing anyone else! It’s brilliant! That’s what my college professor realized. He could perform dozens of tiny experiments in the time it took to set up a single experiment with a population size much larger. Its that ability to try multiple small experiments in order to gain rapid feedback that lies at the heart of all the agile methods!

So why would you waste your time trying to persuade a recalcitrant team to try out your latest hare brained process, when you are perfectly capable of proving it much more rapidly yourself? Not only can you quickly validate your ideas, but you can also refine them much more rapidly by yourself, so that when you do finally reveal them to the team, they have had some refinement prior to being inflicted on others. Hell, they might even work!

Aha! You pounce, you can’t possibly achieve statistical significance with a population of only 1 can you? Well, I’m not necessarily looking for rigorous statistical significance here. I’m keeping things simple and using simple statistical tools (time plots, etc.) to capture just the information I need to discover if I’m “moving the needle” in the right direction. Also, repeated measurements and an ABA design can go a long ways toward validating these simple assumptions.

What about your objectivity? Phah! I don’t need no stinking objectivity! In fact, because it is just me, myself and I, we can take advantage of subjective measures much more readily than you would in traditional large population experiments. Questions like “How do I feel today?” have easy, subjective answers that can prove just as useful as traditional objective measures.

Furthermore, with the advent of mobile devices with rich applications and interfaces we are now starting to see the development of an entirely new class of self-measurement devices. Nike has the “Fuel” bands, my iPhone has mood trackers, workout trackers, pulse monitors. The list of applications is growing with astonishing speed. It is actually leading to a movement of sorts that labels itself the “Quantified Self” movement.

In this new ecosystem of rapidly evolving new tools we have a new wealth of opportunity to experiment with ourselves. With the combination of agile methods we have the ability to rapidly iterate through many tiny experiments on ourselves and help to refine the techniques that we can use not only on ourselves, but on our teams.

Now is your chance to make yourself part of science. Explore your inner Beaker!

Over-Training

In the sports world there is a fairly well understood phenomena known as “over-training”. In broad terms, over training occurs when an athlete trains harder than their body is capable of adapting. It’s generally characterized by a decrease in performance, changes in mood, physiological changes like weight gain and chronic soreness. The remedy for this condition is to back off on the training and slow down. Simply put, the body needs a chance to recuperate.

This is something that is so common and well understood in the sports world that almost any good athletic coach knows what it is, how to spot it, and how to treat it. You see it all the time when you go to the gym. People pounding away on exercise machines, full of vigor and enthusiasm and guess what happens?

Day one – Work out like crazy.

Day two – Ooh sore, keep working out like crazy.

Day three – Still sore, push through the pain.

Day four – No energy, flail through it all based on raw drive.

Day five – Wondering why you ever thought this was a good idea.

Day six – God I hate exercise.

Day seven – You pull a hamstring and limp off to the doctor.

That’s how over-training works. This story is so common that I would be very surprised if anyone reading this has not personally gone through exactly those steps at least once. I know – I have done it myself many times. What’s the first thing that you would tell someone who had just gone through this hypothetical 7 days from hell? Slow down! Pace yourself!

That’s right, it’s so simple to see the pattern that just about anybody could spot it. Who is the one person who can’t see what’s happening? Yes, you got it: the poor guy doing all the work (just too busy, busy, busy). At this point, unless our hero is some sort of expert in physical fitness, he’s probably well advised to seek the experienced help of a trainer or coach.

So that’s fun. Can we over-train elsewhere? Playing the violin? Studying for an exam? Writing code?

I had a friend once who got his first job as a software developer at a small Seattle startup. That was back in the heady days before the boom. He was so excited he could barely contain his enthusiasm. He was going to be working with some of the best developers he had ever met on exciting projects that were going to transform the way we work with computers. It was huge, audacious, and magnificent! He dove in and gave it everything he had. He was so eager that he got up at 5 AM to catch the first bus downtown. He read programming books on the way to work. He coded non-stop until 10 at night and then studied more programming books on the bus home. Six hours of sleep, rinse and repeat. Often on weekends.

For over six months straight.

And then I was my friend was laid off. Poor bastard. So, because I just happen to know this guy pretty well, let’s see if we can ask a few questions (and fortunately he can’t read because he went blind reading programming books on the bus). First, were there any signs of over-training to be found? Why yes there were! As it happened, he started to suffer some anxiety – constantly worrying that he wasn’t achieving enough, not smart enough – the pace was starting to grind him down. His performance started to suffer: his hands might be on the keyboard all day long, but there were increasingly long stretches spent just staring at the screen (not to mention drooling on the keyboard). Weight gain? Check! Twenty pounds, easy. He even developed a mild case of carpel tunnel syndrome. Soreness? Check!

Pretty much a classic case of over-training. And the prescription? Slow down! People told me him to slow down and guess what? It really didn’t help. He couldn’t understand what “slow down” meant. You might as well have said it in Martian. I could see the lips moving, but the words made no sense. How do you explain “slow down” to someone who can’t ever go fast enough? Can’t be done. I had deadlines. The team was depending on me!

The irony of what ended up happening was epic.

The pace that we keep, no matter what the endeavor, really seems quite important. Do it right and you can sustain your pace like a marathon runner. What is most intriguing is that just like in the case of athletics, there are tell-tale signs of over-training in knowledge work. We can and should keep an eye out for those signs. It’s also apparent that, despite a relatively simple prescription (slow down) it can be a tough nut to crack.

So, if I could go back and coach this friend of mine, what would I tell him? What would I say as someone who has seen this pattern before? What would I say as someone who has experienced it himself? I probably wouldn’t say anything. I’d probably just give him a hug.

…And tell him to avoid redheads named Heather

…And don’t play that stupid drinking game with his brother

…And for Pete’s sake, BUY APPLE stock!

Stopping

The other day I was re-reading Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. I was looking for a metaphor for quality used in the book that I remembered reading long ago. I found myself sucked into the book almost immediately and I stumbled across a quote that caught my attention.

Mountains should be climbed with as little effort as possible and without desire. The reality of your own nature should determine the speed. If you become restless, speed up. If you become winded, slow down. You climb the mountain in an equilibrium between restlessness and exhaustion. Then, when you are no longer thinking ahead, each footstep isn’t a means to an end but a unique event in itself.

This gave me pause. You see in software development, this kind of thinking is completely alien. Maybe that’s too broad a generalization, so let me refine that statement a bit: for me, that notion of equilibrium and balance is foreign. You could say it’s all the same. I’ve grown up in the software business. I know how to work all night to hit a deadline, to “sprint” toward a goal. I’ve been doing it for 20 years.

And boy, sometimes I get tired. Really tired.

I once told someone that I have no right to preach the merits of sustainable pace to anyone – because I can’t seem to do it myself. Recently, in a rather dramatic turn of events, I collapsed just prior to a speaking engagement. The pace, the pressure, and the travel just added up to too much. Fortunately, that’s all it appears to have been – stress. Thank God.

But I was left with a compelling desire to…sit still for a while.

It occurred to me that the mountain wasn’t going to go anywhere, so I might as well take a break.

The really curious thing was that I was still restless. I had just been delivered one of life’s little telegrams with the message, “Slow down or die.” I figured most rational people would pay some heed to a message like this. Apparently I’m not a member of that clique (the rational ones). Now this doesn’t come as a remarkable surprise to me, but I did face this revelation with some curiosity.

The question is, why the hell can’t I slow down? Maybe its the business I’m in. Let’s face it: software development is all about going faster. Call it Scrum, call it XP, shucks I really don’t care what you call it. The bottom line is that it’s all about delivering value faster. Of course value is also what Pirsig’s book is about, the subtitle being, an Inquiry into Values. So what are my values? Is delivering fast one of them?

If I look at the agile manifesto, a document that can be fairly said to have influenced my work life quite substantially, I read the following:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Well, there is no reference to going faster that I can read into that. Now you might argue that the principles might state otherwise, but on the face of it, the values don’t have anything to say about how fast we delivery software.

Of course with all the running about that I tend to do, it may just be that I’m a lot lower down on this metaphorical mountain than I had previously thought. You see, I’m not sure I’ve had much practice at this stopping game.

Maybe it’s like this: when you learn how to ride a bike, the first thing you learn to do is learn how to get going. How to get started. How to initiate the process. Once we do that then we need to learn how to keep it going. How to sustain our progress and navigate through unexpected turns. Finally, we need to learn how to stop. It could be a gentle glide or a power slide, but stopping is just as important as starting.

Frequently I see teams that in some very important ways seem to have mastered the first two steps, but seem to struggle when it’s time to stop. There are all kinds of reasons to stop when working on a team. For instance:

1) at the end of the release

2) at the end of the day

3) at the end of the sprint

4) when something goes wrong or breaks

5) when someone notices something out of the ordinary

6) when the team is done

The funny thing is, like a lot of things that I observe on teams, I see these reasons for stopping in myself too (I have a list of things to stop that is very nearly ten times that long). So I have become very curious about this “stopping” thing. Frankly, I find it all a bit terrifying. It feels risky to think about stopping. So I’m approaching it with due caution. Dipping my toe in the slow pool – starting with some meditation.

So, I take the time to stop and do nothing a few times a day. I just sit there and listen to the hum of the world whizzing by. I’ll be honest, I can’t tolerate it very long before I am sucked back into the frenetic pace of “the game”. It’s an experiment. An attempt to practice that crazy stopping thing. I have to admit it’s kind of nice…sometimes.

So, that’s where I’m at. This post has meandered and digressed and gone nowhere in particular. That feels about right. This is probably a good place to stop.

The Fat Man Manifesto

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”

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

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.