Friday, September 27, 2013

Generation Agile

When I posted on twitter earlier this week about the presentation my wife and I gave at the Global Scrum Gathering, Paris 2013, on The Agile Girl Scouts, a friend of mine asked me to put some context around it. He was able to understand that this was a pretty big deal to me, but was't sure why. My hope is that this blog post will provide some explanation around that.

The Waterfall
Most adults in the workforce today have learned how to manage work using a waterfall model. That means work follows something along these lines:

  • Initiation - We figure out what we need to do
  • Planning - We figure out how we are going to do it
  • Execution - We do it and try to follow the plan as best we can
  • Monitoring and Controlling - We check to see if what we delivered is what was wanted
  • Closing -  We shut it down and capture what we've learned along the way.

Bag of Oranges Days
For many of the people who adopt this method, success comes from a command and control approach. This approach tends to view people as "resources" which are expended on a project to achieve a specific end. In the IT space, it has a history of being successful about 30% of the time. For the person acting as Project Manager, it often leads to a lot of "bag of oranges" days.

When I learned and later began teaching this model, I kept wondering why no one had taught me that stuff before. The simple tools it provided, seemed more like common sense. Just having the simple capacity to see an overwhelming amount of work and have the basic tools to break it down into manageable, workable elements was very enlightening. Since then I have been looking for ways to go back and teach my younger self some tools that would have made life a lot easier. 

Those tools were great, but using them was a bit like Frodo putting on the ring. The more I used them, the more I started to feel that I was supposed to try and control the uncontrollable and the more I started to view the humans I worked with as "resources" and not people. They were pawns on a chess board and I was playing chess against an opponent I could not hope beat because the only thing I could be sure of was that whatever I was able to imagine, predict, or plan for, was the only thing that was not going to happen. 

When I entered the workforce and started to work for people who had been taught that success came through control, I was often the pawn on the board. In many jobs I was micromanaged, condescended to, accused, blamed and generally treated like someone who could only be counted on if they were bossed around and threatened. I, in turn, reluctantly learned this approach and tried, to apply it (with limited success). This didn't happen all the time. I was lucky to have a few really great bosses and teams along the way and I was fortunate to find myself in situations where I really was able to be creative and collaborate with other people who cared as much about the work as I did. Those moments were invigorating. 

The Agile Manifesto
As part of a response to the waterfall approach, in 2001, a bunch of smart guys got together and came up with the Agile Manifesto, which says: 

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
In my journey towards adopting the above and learning to use the models and frameworks which support the Agile Manifesto, a lot of what I do is a reaction against the traditional command and control approach I had been taught.  I often joke that I am in a state of recovery, but I do tend to view it that way.  One of the reasons I get so much joy from what I do for a living is that  I get to help others on their transition as well. But I do think it is important to acknowledge it as a corrective action. 

Hope for the Future
Any parent wants their child to have a better life than they did. We all want for our kids to experience less adversity (or at least different adversity) than we did. If Agile is about creating a work environment that values people, their ideas and ability to collaborate in an effort to deliver higher quality work, then it is a very positive and healthy response to a workspace that did not support creative collaboration and self-organization. 

Each new generation finds that certain things which were common in previous generations, are no longer good for us. When I was a kid we'd go to the Jersey shore in the summer. If my Mom was able to get some Coppertone SPF2 or 4 on me it would only last until I was able to get to the water and scrub it off. I'd play, swim and lay in the sun until the blisters formed. The blisters were an indicator that maybe it was time to put on a t-shirt, a baseball hat, or in extreme cases, SPF 15. My daughter has been spared that due to how much more we know about the damage the sun can do to our skin.

My goal with teaching Agile to young people is similar to educating them about the dangers of too much sun. My hope is that if they learn about Agile first, their experience with it and exposure to the benefits it can provide will "inoculate" them against some of the challenges they would otherwise face if they entered the workforce as "resources" to be used up on a waterfall project. My hope is that they will see Agile not as a response against something else, but as a natural, organic way for empowered, creative people to deliver high quality work. 

Friday, September 20, 2013

Ninja, Baker Priest

In the Agile and Scrum classes that I teach, one of the topics that seems to cause a fair bit of stress, or at least, more than it should, is Cross-functional Teams. The stress tends to be rooted in a misinterpretation of what cross-functional means.

So first, what it doesn’t mean is that everyone on the team has to have the exact same skill set.  That would probably make finding people to work on the teams pretty tough. Everyone has things they gravitate towards and develop a certain amount of expertise in. Finding a really talented graphic designer who can code like Neo and is still willing to write documentation is unlikely. But we still want to have a team of people who have some ability to help each other out.

When I think about these things I sometimes find it helps to consider it outside of the context of Agile and Scrum.

Example 1: The A-Team

In 1972, a crack commando unit was sent to prison by a military court for a crime they didn't commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, still wanted by the government they survive as soldiers of fortune. If you have a problem, if no one else can help, and if you can find them .... maybe you can hire The A-Team.

In the A-Team, everyone has a role:

Hannibal – the Planner and Visionary
Face – The Master of Disguise (and Social Engineering)
Murdoch – Pilot of anything that can fly and team Wildcard
BA – Wheel Man and Muscle

Now, BA hates Murdoch. Actually, that’s not really true. BA pities the fool. He does not trust Murdoch because

1) Murdoch is certifiably insane 
2) BA hates to travel by air. 

So, every time they have to fly, Face or Hannibal has to slip BA a mickey finn or a needle and put him out.  While he out, they travel by air. When they land, someone has to drive. This role typically falls to BA because it is his primary area of expertise. However, if BA is still knocked out. Someone else has to drive. The other team members do not necessarily have to be as good at driving as BA, but they have to be able to drive well enough to get from A to B and possibly evade some law enforcement along the way.

Example 2: Ninja, Baker, Priest

Let’s say you have a team comprised of a Ninja, a Baker and a Priest. As part of the work they have committed to for the Sprint, they are responsible for taking steps which will result in the death of Mr. X.  Since the team has a Ninja on it, this should be no problem at all. But what if the Ninja comes down with a terrible case of the sniffles. He (or she) can’t exactly be a silent agent of death if they have to stop and blow their nose every 5 minutes.

So, the team has a meeting and discusses the situation. It is agreed that the Ninja should stay home, have come chicken soup and try to get better. In discussing the work, the Priest and the Baker agree that between the two of them, the Baker has the most experience with knives, so he agrees to head out and complete the contract on Mr. X. The only catch is that the Baker also had work to do. Fortunately, the priest has been well trained and has been known to be able to do some pretty cool stuff with Bread too, so he will help the Baker while the Baker is helping the Ninja.

So, the idea of cross functionality is that the team has or develops the ability to help one another when they need to. It is not that everyone on the team develop the exact set of skills. Once they have made a commitment, they are responsible for meeting it. If everyone on the team has a specific skill set that is not shared, a smart team will take some tome pairing or cross-training to remove single points of failure.

This is just a simple explanation. For me, these kinds tend to work the best. If you’d like something that digs a little deeper on this topic, I’d recommend checking out Heinrick Kniberg’s post on Crisp.