The Heart of Agile

At the heart of Agile are teams, real teams. I am not talking about the "team" that is a group of people who report to a manager. That is typically just a working group, whose members:

• Work independent from each another
• Specialize in a few things
• Have individual goals
• Are management driven and controlled
• Have specific job descriptions.

That is not to say that working groups don't work. Working groups have been used to create products in non-agile environments for years. However, in an agile environment real teams are the critical piece that holds the "agile fabric" together. Pull out the team "thread" and the entire fabric starts to unravel.

At first, no one notices that the fabric is unraveling. Annoyances to the team start to appear that are attributed to agile practices. Annoyances such as:

• Nobody cares about your status at The Daily Standup
• The Iterations are not long enough to get anything done
• The Definition of Done is too hard to achieve.

The annoyances pile up until agile is declared broken and "can never work here".

So, if real teams are so critical then what are their attributes and why are those attributes valuable to helping agile succeed? Here are some attributes to think about:

• Team size: 6 is a great size, 9 is starting to get on the large size. If a team is too large then they don't all communicate and collaborate with each other frequently enough. In which case why not just create a smaller team?
• Self-organizing: The team decides how to best accomplish their work. Self-organizing allows team members to be highly collaborate and to feel ownership for their work.
• Cross functional: Members of the team have varying functional skills required to do the work and importantly, the team members are willing to do work outside of their specialty. Cross functional teams help reduce the need to queue (batch) work for specialists. Reducing queues helps to minimize work in process (WIP) - fundamental to succeeding with agile.
• No job titles: On a team there are no developers, testers, documentation people, etc. There are people that have development, test, documentation, etc. skills. It is expected that the team pulls together to figure out how to best accomplish the work (i.e.: self-organizes) with the set of skills that it has or that it can acquire.
• Keep the team together: Think about bringing work to teams. Seriously avoid forming teams around the work. A bit of change to the team members is acceptable, but I'm talking about keeping the team together unchanged for many months and perhaps a couple of years. 
• Dedicated: All the team members are dedicated to the same goal. People are never allocated to multiple projects.
• Highly collaborative: The team members collaborate frequently to accomplish their work. It certainly helps collaboration if they are working on the same stuff.
• Co-located: The team members are all located in the same area, preferably in a team room. Radical co-location can double the output of the team.
• Shared vision and purpose: The team has a clearly defined vision and understands their purpose as a team. It is difficult to act as a team when members are working at cross purposes and do not all have the same vision for their being.

So far I have described the structure and attributes of teams. That alone is not sufficient for success. The team needs to make two commitments. These are team commitments, not individual commitments.  The two commitments are:

1. The team commits to quality. Quality means that they have the vision to delight the customer in what ever they create. No need to talk about defects here; I have never seen a customer delighted with defects.
2. The team commits to working professionally. Working professionally has many meanings including positive attitude, using the right tools, and working together.

People on the team hold each other accountable to these commitments. Avoid individual commitments driven by people external to the team as it will weaken the team.

There is one commitment that the team does not make. The team does not commit to time (i.e.: quantity of output).

If they were to commit to time then quality will suffer. If the organization is really committed to quality then we have to stop trying to stuff 10 pounds of mud into a 5 pound sack — i.e. we need to start matching the capacity of our organization to deliver against the desired features. There are certainly reasons to balance between quality and time; beware of the slippery slope!

Hope

A recent CBC Radio story that stuck was from the a show called Tapestry. The show was titled Hope and I happened to tune in right around the time when these two quotes came over the air:

"Hope is the worst of all evils, for it prolongs the torments of man." -- Friedrich Nietzsche

"Hope deceives more men than cunning does." -- Marquis de Vauvenargues

What is going on here? I had always hoped that hope was a good thing. You know, "We send our hopes and prayers", "I hope that you have fun", and "Here's hoping that all goes well". Nietzsche is saying otherwise. Heck, "worst of all evils" doesn't sound too pleasant.

But when I think to the projects that I have worked on in the software development world the word hope keeps slipping in there too. You know the phrase, you probably hear it a couple time a day: "I hope to deliver that stuff soon.". What is hope doing there?? Someone has asked for a commitment and the response was "I hope".

What “hope” really means here is that the person has an impediment and that they could use some help. Help focusing on one task. Help understanding the technology. Help understanding the domain. Impediments come in all sizes and shapes and worst off they can be very well disguised.

Watch for the hope word; don't ignore it and just hope that things will get better. Take the opportunity to find out why someone is offering hope instead of a commitment. Perhaps an impediment will surface from the depths and people will be able to talk about it and even perhaps finds ways to start solving it.

Missing the Target

I work with teams quite a bit. I help them understand practices that will lead to better software. Inevitably during the description of some practice I hear the words “that will never work here”. The phrase seems universal, almost like “Kleenix” is to facial tissues.

Take TDD for example. I describe the basics – red, green, refactor. “Wow, cool” they say. This is followed closely by “but that will take too much time” or the ever popular “we can’t possibly add tests to all that legacy code”.

I don’t expect teams to hit the bull’s eye (for that matter I don’t expect myself to hit the bull’s eye either!). I do hope that people will try. I also hope they understand that failure is an option. Actually, failure is a darn good option; so much learning can come from failure.

And here is the point. Set your eye on the target. Take aim and practice, practice, practice. Eventually you will hit a target. It might not even be the target you originally set out to hit. That too is learning!