Team Genetics

September 28, 2014

dna-163710_640

Today I was listing to “The Splendid Table”, a great cooking show on NPR. They were talking about variation in growing heirloom tomatoes. Somehow, that got me thinking about agile teams (probably time to see the therapist again). It occurred to me that ideas like Agile are memes.

Richard Dawkins defined a meme as “an idea, behavior, or style that spreads from person to person within a culture.” and Agile certainly fits that definition. Agile has spread from obscurity to worldwide acceptance within 20 years. In another 20 years I fully expect that waterfall, plan driven methods will be nothing but a footnote in the history books. Despite some early prognostications to the contrary, Agile has grown at a very healthy rate over the last several years.

“Richard Dawkins invented the term ‘memes’ to stand for items that are reproduced by imitation rather than reproduced genetically.”

While much of the credit belongs to the teams that actually do the hard work of making a new process work, there is also the business that has arisen around evangelizing and introducing Agile to companies that deserves a great deal of the credit. Agile training and consulting has done a remarkable job of spreading the meme throughout the software development world.

I think there are characteristics of Agile training that have made Agile “sticky” as a meme. Much of the Scrum certification is based on plenty of hands-on exercises. Training and certification has yielded a decent business. I’m not sure if anyone has the numbers, but I’d be surprised if it wasn’t a multi-million dollar enterprise worldwide. Strangely enough, much of that spreading has been through imitation. There is no shared agenda for the training, much of it is simply imitated from trainer to trainer.

When trainers and others spread the meme they are like Johnny Appleseed sowing Agile ideas across fertile corporate soil.

Genes change with each generation, and so do ideas. They go through a mixing and blending each time they are shared. Parts of the idea are forgotten, other new ideas are grafted on. Soon the original idea is unrecognizable. I think that’s kind of what has happened with XP. Extreme Programming originally contained a collection of ideas that were very potent. Things like pair programming, continuous integration and others all served as core ideas within XP. Over time, those ideas have been co-opted and found their main expression in Scrum. Today, almost no one trains teams in XP, Scrum is the dominant process that is trained and introduced to teams.

“Memes do this through the processes of variation, mutation, competition, and inheritance, each of which influence a meme’s reproductive success.”

So too does Agile. In recent years methods like Kanban and ideas like No Estimates have arisen and are becoming a meaningful part of the software development landscape. These are evolutions of the Agile meme. Agile is evolving, I wonder where it will go next…


If Everybody’s Happy, You’re Doing It Wrong

August 11, 2014

So there you are, wrapping up another successful release planning session. Sprints are all laid out for the entire release. All the user stories you can think of have been defined. All the daunting challenges laid down. Compromises have been made. Dates committed to. Everyone contributed to the planning effort fully.

So why isn’t everyone happy? Let’s check in with the product owner: The product owner looks like somebody ran over his puppy. The team? They won’t make eye contact and they’re flinching like they’ve just spent hours playing Russian roulette. What’s up? Well, here’s the dynamic that typically plays out:

  • The product owner has some fantasy of what they think they will get delivered as part of the release. This fantasy has absolutely no basis in reality, it just reflects the product owner’s hopes for what he/she thinks they can get out of the team (it’s just human nature). This is inevitably far beyond what the team is actually capable of. My rule of thumb? A team is typically capable of delivering about 1/3 of what a product owner asks for in a release. That’s not based on any metrics, its just an observation. However, more often than not, it seems to play out that way.
  • The team is immediately confronted with a mountain of work they can’t possibly achieve in the time allotted – even under the most optimistic circumstances. It’s their job to shatter the dreams of the product owner. Of course, strangling dreams is hard work. Naturally enough, the product owner doesn’t give up easy. They fight tooth and nail to retain any semblance of their dream.
  • After an hour, perhaps two, maybe even three or four (shudder), the battle is over.

I’m going to go out on a limb here and speculate that this is no one’s idea of a positive dynamic. But it seems to happen pretty often with agile projects. It sure doesn’t look like much fun. I’m pretty sure this isn’t in the Agile Manifesto. So how do we avoid this kind of trauma?

  • The product owner needs to be a central part of the team. They need to live with the team, be passionate about the product, and witness to what a team does daily. Fail to engage in any of this and a product owner loses touch with the work the team does and loses the ability to gauge their capabilities. Doing all of this is hard. There’s a reason that the product owner is the toughest job in Scrum.
  • The team needs to embrace their product owner as an equal member of the team. You have to let them in. Work together. Let go of the roles and focus on the work.
  • Prepare for the release planning in advance. There is no reason for it to be a rude surprise. Spend time together grooming the backlog together. As a team.
  • Don’t cave to pressure from upper management. Behind every product owner is a slavering business with an insatiable desire for product. Ooh, did I just write that?

Release planning doesn’t have to be a nightmare. OK, in theory…