Keeping Process Alive

New year, new conference, new blog entries - this time I am attending the JAX'08 and I have just an interesting opening "Agile Day" behind me. This was all about agile development and management practices and how these can be introduced into an enterprise, which has no experience with them yet.

There are many agility-oriented consultants that know how to enable the transformation of a team or company towards an agile player. This is not an easy path to follow, but with enough social skills, it should be possible to get things going. It is key to success to have full support from management as well as from the team members. If any side has doubts or does not welcome any change, the transformation project might be doomed before being started.

Now imagine that despite all possible obstacles the transformation was a success and your department is now following appying agile practices. The external consultant leaves and you are left on your own. What happens? For a while, it is taken as normal that after such a big organisational change there is still some inclarity about one thing or another and one tries to figure out how to fill the gaps. Usually one fills the gaps with something that one is familiar with and so this will bend the agile process a bit towards the "old" style to do things in the department. As things are not smooth yet (to really "live" agile practices, people might need several months or years) and so no real improvement can be seen and only few people will be enthusiastically support it (now that the expert as a backing is missing). New people will arrive, others will leave the company. Spin this further for a couple of months to a few years and most of your agile process will have eroded. It is likely that all you will see that is left is continuous integration - that's the one practice that is so immensely successful, that nobody wants to miss it and so its wide acceptance is almost guaranteed.

But what to do to avoid the erosion of the rest of your practices?
From what I learned there are a few key things that you need to make sure on the long run:

• In each agile team, you must have at least one change agent that actively persues the agile way and continuously drives the team to follow the practices and to improve its adoption. "Supporters" of the agile way are not sufficient - if things start to slip, the change agent must take immediate action, so he plays a very active role.
• New team members must be fully introduced into the practices - not by provided some Wiki pages with coding conventions to follow, but with an active mentor or foster parent during the initial weeks or months.
• You need to pay special attention to your retrospectives - these really forces the whole team to think about the process, where it is not appropriate and what can be improved. Only by these retrospectives it can be achieved that team members identify themselves with the practices and see it as something that they really own (and therefore need to care about it).
• Progress should be made visible (e.g. in burn-down-charts) and achievements should be celebrated - each successful iteration motivates the team members and it gives confidence in the ability of the team to the team itself as well as to the management. A positive effect is also that with each iteration, future estimations will become more precisely.

If you respect all of the above points my guess is that you have a good chance that your people really pick up the agile way, live it and improve it. That's what you should be striving for.