Cooking in the Scrum kitchen – What Does Your Kitchen Look Like?

July 23, 2008

Maybe I’ve been watching too much reality TV lately.

You know how the formula works: put a room full of talented people under unreasonable amounts of pressure and then turn the relentless eye of the camera on them. Bring to a boil, then stir occasionally. Whenever I see that recipe used I end up thinking to myself, “Hey, that’s just like software development!”

Of course everyone’s project “kitchen” is different. Some projects feel neatly organized, there may even be a matronly figure who cares for the team. All the knives are in the knife drawer. The dishes are clean. This would be a “Julia Childs” type of project.

Maybe you don’t have Julia around. Maybe your project kitchen has lots of sharp objects lying around. Perhaps the burners on the stove have only two settings: frigid and flambe! Everyday is an adventure in this kitchen, and only the strong survive. Call it “Hell’s Kitchen”.

What’s the point? Well, we all find ourselves in different environments when we are working on projects in one way or another. It helps to recognize the kind of environment we are in. More than once I have found myself dodging flying cutlery and thinking, “What did I do wrong?” Sometimes it’s not you at all. Sometimes it’s just the kitchen. Different cooks do well in different kitchens. Recognizing the environs we do well in is critical.

I had an opportunity to sit with two different teams on the same day recently and they could not have been more different. They each had many of the same tools at their disposal. Both were using Agile development. Both had similar levels of technical expertise. One meeting was a struggle – nothing came easy. The other breezed by with nary a problem.

Swarming Meets “The Blob”

July 22, 2008

The more I read about slime mold behavior the more I think the blob was seriously under-appreciated. Bear with me here. In a nutshell, slime molds are individual cells that, under the right environmental conditions, can band together into a colony that exhibits complex emergent behavior that you would never expect of it’s single celled components. It is a classic example of a self organizing group that, like other creatures that swarm, can make relatively complex decisions about their environment. Believe it or not, a slime mold colony can actually solve a maze!

An let’s face it, what is a man eating blob from outer space really made of? I bet it was just a slime mold. The blob was probably just misunderstood. There it was, on a strange planet, no friends, no one to talk to, not even a myspace page. It really is all just too horrible to imagine. Fortunately, there was a ready supply of food close at hand – teenagers!

However, despite a predilection for poor decision making (“Hey, let’s make out in the back of the car…did you hear something?”) teenagers seem to be relatively quick on their feet. A blob has to do a lot of work to keep up. Decisions have to be made. Let’s put ourselves into the mind of a blob…OK, maybe not the mind. Let’s join the colony for a while and see if we can get a little insight into the inner life of a killer alien from outer space.

So there you all are sitting on a street corner. Just you and 20 million of your closest unicellular friends. You’re all probably feeling a mite bit peckish. Dinner is in order. But where to go? There is the malt shop – plenty of teenagers there – but maybe you are trying to lighten up on your carb intake. Or you could roll on over to the movie theater – Lots of food in a dark, tightly confined space. What would you do? Go for the kids with a little chocolate on the side, or do you catch a movie and snack on a few teenagers during the show?

So, the next time you come across a killer alien blob from outer space rampaging through your idyllic little suburb, remember, swarm intelligence is not easy! Try feeding them the neighbor’s poodle, and have a little sympathy for the slimy.

Trust Your (Bleep)ing Team!

July 20, 2008

Here is an issue that has come up over and over again – scrum masters and product owners that don’t trust the teams they work with. I’ve struggled with this problem myself over the years, so I can definitely relate to the mistrust. Here’s my favorite example:

Sandbagging: The team is not delivering 100% of their stories each sprint. The team is not pulling as much work as you would expect each sprint. Everyone is coming in late and leaving early. No one is staying late nights to make sure that stories are absolutely done before the end of the sprint.

There you are as the Scrum Master, tearing your hair out in frustration, trying to figure out how to get the team to step up and deliver. Well, if this goes on for very long, you end up not trusting the team. After all, their commitments seem to mean little, they just go through the motions, etc. Of course, here’s a news flash – they don’t trust you either. In my experience, teams can almost always read you like a book. They know it when you don’t trust them. They know it when you think it’s “their” problem. They aren’t stupid. This just further increases the sense of alienation between the two sides. It further limits your ability to be an effective member of the team.

I think that often times when we get to that place of mistrust we are doing something very fundamental and very destructive to the relationship with the team. We are making the problems, what ever they may be, someone elses problem. It’s the team’s problem, not yours. It is something that is inherent in their nature – they are somehow flawed. If they would just somehow, “Get it” then our problems would be solved. Of course nothing could be further from the truth. The fact is that everyone plays an important role in this dance of trust. If you really want to address the problem, you have to be ready and able to take responsibility for your part in the problem. Because as scrum master or product owner, you are part of the problem, like it or not.

So what is the solution to this problem? Trust your (bleep)ing team! That’s right, get that mistrust monkey off of your back – take it from me, that particular simian has nothing constructive to offer. Let the team know that you trust them completely – 100%

You’re never going to make significant progress as long as you and the team distrust one another. Guaranteed.

Then start looking for the impediments that are holding them up. Maybe the first and most difficult impediment to remove is any mistrust we may have with the team.

Do Donuts Exert a Gravitational Field?

July 16, 2008

A few years ago I went to the Apple WWDC (World Wide Developer’s Conference) in lovely Cupertino California. I was kind of a loner at the conference. It was my first time. I was by myself and I didn’t know anybody. But I had a Mac.

Being the person that I am, I often felt like I was on the outside looking in. It was a very sociable crowd. People would get together in the hallway, sit right down on the floor, break out their titanium PowerBooks (OK, I’m showing my age), and start writing code. The halls in the convention center left ample space for this kind of interaction. I suppose, if I were really cool, I would have been in one of those groups. However, often times it was just me reading my email and waiting for the next session.

Sitting there, staring out over the hall, I had an excellent vantage point for observing my fellow Macintosh fanatics. Each morning started the same way. Around 9ish we would all stumble into the main hall. In the middle of the hall would be dozens of tables seemingly arranged at random. Upon each table a pyramid of Krispy Kreme donuts towered nearly 3 feet in the air. Literally hundreds, nay thousands of delicious donut delectations per table. Decanters of coffee lined the walls of the hall. I never saw anyone set them up – it must have been the donut fairy.

You should have seen the feeding frenzy that would erupt each morning. The ravening hordes would descend upon the innocent stacks of fluffy goodness and attack without remorse. But even the starving appetites of the Apple Illuminati could not defeat the towering Krispy Kreaminess. The mighty pyramids of sugary goodness might buckle and sway under the onslaught, but they seldom fell in the first assault.

It was with a sort of sick fascination that  I observed the carnage taking place, the floor gradually getting sticky near each table. I saw a pattern emerge: observe any individual in the crowd and they would act as if the tables of donuts exerted a mysterious gravitational field. They would grab a pastry and and walk away from the table, munching contentedly and bearing an expression usually only associated with hardcore narcotics. Curiously however, their path began to describe a  parabolic trajectory as they arced away from the table, reached the apogee, and then inexorably returned along their orbit to the table they had started at – helping themselves to yet another hit of the sugar filled tranquilizers.

I watched many a poor soul trapped within the sugary gravitational field of those tables, unable to avert my gaze. Good men! Decent men! Men who had families! Doomed men. Sometimes you would see a particularly pathetic example: someone caught in the gravitational tug of war between twin towers of donuts. Orbiting the two tables in a gigantic figure eight pattern. Forever to repeat their path, wearing a hole in the carpet, until either the donuts were consumed, or they were carried off on a stretcher in a diabetic coma by the convention center staff.

I have seen the face of madness and it lies like an alluring young siren in a lush field of all-you-can-eat donuts.

Upcoming Swarming Presentations

July 12, 2008

As we get closer and closer to Agile 2008, Dhaval and I are spending a lot of our time refining our presentation, Swarming: The Birds and the Bees and Agile. Here are some upcoming events where we will be giving the presentation:

If you get a chance, come on by and say hi!


Who Do You Tweak?

July 11, 2008

Yourself or the team?

Recently I’ve been coaching a team that is full of wonderful people, but in all honesty it has to be some of the hardest work I’ve done in a long, long time. Trying to get us all through the maze of neurosis, conflicts, petty jealousy and uncertainties has been enough to drive anyone nuts. We’ve made some terrific progress, but it has been slow, deliberate work. There haven’t been many dramatic breakthroughs. We aren’t hyper-performing. Hell, sometimes I think I’ll just be happy if we can make it to “stable”.

Along the way I’ve noticed something funny happening. When I first joined the team, I was told they were the “problem team” for the organization. Much of my early approach to coaching the group might be described as “tweaking” the rules that the team operated with. By tweaking I mean trying out different ways of working with each other that seemed to best address the myriad of problems we faced. Early on, I was definitely the one who was tweaking them (with the team occasionally tweaking me back just to keep me from getting too cocky).

But I found that I could only get limited success by treating the team as a black box with knobs on it that needed adjustment. A good friend of mine pointed out that I was still referring to “them” as the problem team. I realized that the “me” vs. “them” dichotomy had to be eliminated if this was going to be a success. Easier said than done.

That meant I really needed to become one of the team – in essence, I needed to tweak myself a bit. I had to take off the surgical gloves and dive into the black box with the rest of the team. Changing the rules had to impact me just as much as it impacted them. I found myself spending more time focused on my own behavior (in relation to the team) than on their behavior. Am I allowing them to speak their minds? Can I really give up control over certain things and still be a good coach? Nebulous stuff to be sure. These days, I’m no longer really sure who I’m trying to change – the team or myself. The line is blurred. Sometimes it is uncomfortable, but I must say that I’m much happier with the result. We’re making great progress. I caught myself telling someone today that “we rock!”

So I guess I’m coming to realize the being a coach is not just about being skilled at influencing others – it’s also about being willing and able to change yourself. Rock on.

Frequent Small Releases

July 11, 2008

With scrum, we try to deliver business value every sprint. That’s easier to do with some projects than others. If you have a mountain of technical debt facing you, delivering business value every three or four sprints can be a huge achievement. You might get lucky and find the occasional creative way of delivering business value quickly and easily, but most of the time you simply aren’t going to be able to manage it. Forget about it.

There are a lot different factors that make up a technically mature team, and they often take a long time to put together. Until you overcome those lower level issues, you won’t be able to properly address the higher level issues related to delivering business value quickly. Here is a graphic that I use to help make my point:

There are different levels of technical competence that need to be in place in order to support the rapid delivery of business value. If any one of these levels is missing, it is very unlikely that a team will be equiped to manage their work efficiently enough to deliver business value on a rapid and consistent basis. Teams need to be using source control tools and practices. Until they have source control, a team will not have the technical foundation in place to begin to put continuous integration in place. Once you have continuous integration working, you really aren’t getting the full benefit unless you can provide automated tests with every build. So on the technical side, a team has to have a lot of infrastructure in place in order to even think about delivering business value quickly.

There is another side to this issue that is very much tightly releated – how large are the releases that we make? Here is another diagram:

Here, instead of talking about technical maturity, we are looking at deliverables. At a relatively low level of process maturity, a team is really only capable of delivering files and resources with any real frequency. As the team becomes more technically adept, they are able to deliver components more frequently. As you can see, as the team becomes more and more efficient, they are able to deliver features and ultimately meaningful business value on a rapid schedule. These two hierarchies, the technical maturity and the deliverables maturity are linked tightly together.

So what’s the point? Well, if you are working on a team that is just adopting agile, don’t let anybody tell you that you are going to be delivering significant business value frequently – especially if you are like most teams and have a fair amount of technical debt accrued. It’s not that you can’t get there – you can, but it’s probably going to take a lot of work before you are able to deliver on that promise. People tend to expect immediate results when they switch to agile, and I’m here to tell you that often it just doesn’t work that way. If your teams are anything like the ones that I have worked on, you have a significant number of technical, personal, and other issues to overcome before you are going to be able to deliver the promised frequent delivery of business value. It’s definitely the way to go – I’m not saying it isn’t worthwhile, I just think expectations should be reasonable.

In the meantime, instead of trying to deliver business value every 5 mintues, why not focus on Frequent Small Releases (FSR) instead? Yeah, you heard me right. Learn how to deliver something – anything – frequently first. It’s all part of building a mindset of frequent releases that will ultimately (once the team is ready) culminate in the hallowed goal: the frequent release of business value.



July 11, 2008

Look out Heidi Klume, I’m taking up modeling!

OK, maybe I won’t give up the day job just yet…

Sometimes I think there is no better way to teach something than by doing it. By modeling the desired behavior. Sometimes people just don’t want to trust you. They won’t beleive it until they see it. Especially when you are trying to sell them a new process. Maybe that’s the way it should be.

It’s one thing to believe in a process and share the perceived benefits, but it’s quite another thing to demonstrate those benefits yourself. As agile practitioners I think we need to prove our case to our stakeholders and our teams. To teach by doing. We have to demonstrate what a high performing team looks like. Sometimes people need to see it first. Words simply do not suffice.

Getting down and dirty and working on a team also tends to be a cleansing experience for me. A lot of the B.S. that I sometimes buy into will not withstand the metaphorical blowtorch of a team struggling with real, messy, problems. That’s a healthy thing.

Modeling also helps to remind me that I like working on small teams. I like the commeraderie. I like the challenge. And modeling also reminds me, usually with a swift kick to the head, that process won’t solve all of the worlds problems. Sometimes it doesn’t matter whether or not a team is agile – sometimes there are forces at play that agile development can’t help us with. In those cases, you may model and fail. Call it a learning opportunity.

So the next time that you feel frustrated that “they just don’t get it!” Maybe it’s time you tried a little modeling.

New Site Dedicated to Swarming Teams

July 10, 2008

A friend of mine, Dhaval Panchal, and I have been working on swarming quite a bit lately in preparation for our Agile 2008 presentation on the topic. We have set up a site that contains much of the information that we have unearthed on swarming so far. It’s in it’s infancy, but we want anyone who has an interest to contribute. Here is the URL:

Check it out. Let me know what you think. Add to the discussion. I’m really excited about this topic and I want to get as many people as I can to join the fun!

Best regards,