Learning agile by practice

There have recently been some blog posts about agile not producing the expected results. Posts from Martin Fowler, James Shore, Ron Jeffries and George Dinwiddie give some background to this growing feeling.

I like this quote by George Dinwiddie:

The bottom line is that the developers have to learn to recognize what is “better,” they have to learn how to do it

This is aligned with my view on the subject.  You can’t just start with a group of people that have no experience in agile software development.  I even believe that being coached is not going to do the trick.  The best result I’ve seen is the combination of coaching and experienced team members.  You need to have skilled people that are involved in the daily development of the product.  They will teach the team all the practices from bottom up.  Most agile coaches focus mainly on the process side of agile.  Getting the iteration flow installed, using the product backlog correctly, assuring the customer is tightly involved, etc.  But in order to be able to deliver working software every iteration, you need the practices as well, ex. TDD, pair programming, refactoring, …  These are skills you can only learn by applying them in real life projects.  Beside those two, the team has to make sure they keep the link between the practices and process alive, otherwise the whole thing will slowly collapse.

When your team is only performing well on the practices, you tend to get technical excellence with low business value that doesn’t meet the customer requirements.

If your team is only performing well on the process side, you tend to get a product that has high business value with low technical quality.

The best agile teams I’ve seen are small teams.  Maybe that’s just logical.  The smaller the team, the easier the communication, the better it can be managed, etc.

Perhaps a good strategy to start with agile can be:

–          Start small

–         Grow slowly

Tags: Agile, software development, strategy