CHAOS AND DISCIPLINE

On our current project, the team has just spent four days of work on a requirement, to finally throw the code over and start again. We got glued into some never ending refactoring which never gave satisfaction as the code never seemed testable. What a waste! We've been through the same experience already a couple of times - and hopefully we are learning from our mistakes.

We develop near chaos. This isn't a bad thing. We follow practices very close to eXtreme Programming and Scrum, so unclear requirements and emergent systems are our lot. So, why has the team suffered so much lately?

We lacked discipline. In fact, we let go just a little on two major and very constraining disciplines. The problem is that when you develop near chaos, you cannot afford to let go of these two disciplines.

By the way, some people really misunderstand agile development. They believe agility means lack of discipline and chaos. Isn't it just the contrary? To develop in a chaotic environment (such as any software development) you need to be so extremely disciplined! Isn't eXtreme Programming such an extremely disciplined methodology?

So, what are these two so important disciplines? Very frequent synchronisation and test-driven development.

On several projects, we've noticed that shortly after a pair or a single developper gets late to synchronise and deliver his code, he gets stuck in painful code and test merging. The system emerges so quickly that members of the team must keep the rhythm. Stock of undelivered code just slows you down and requires energy to catch-up. Stock means waste! Unfortunelty, it is very difficult to learn how to develop in baby steps. Developers often assert that their current task cannot be cut into small increments.

We've also noticed that developpers tend to slowly let go of test-driven-development. The problem is that they take several successive design decisions to finally discover that their code is difficult to test! Therefore, the design is inadequate and must be refactored and tested.

OK, developers gradually let go of frequent synchronisation and test-driven-development. How do you improve your habits and maintain discipline?

The solution we try is to spread good pratices and systemize checking.

• First, the team shares the same office. Therefore, everyone detects a developper or pair struggling on painful merges. Help and advice is naturally provided.
• The team attends a daily short and focused stand-up meeting. Lack of progress and painful struggling is detected. Again, help and advice is quickly provided.
• Pairing is very frequent. The teammate is there to remind the pair to work in baby steps and write tests as it writes code.
• We have a coach on the team. He's responsible for having the practices applied, training the teammembers and helping the team to continuously improve its practices. The coach detects pairs or single developers struggling in merges or falling late to deliver. He must provide advice and help. He visits the pairs and reminds them to synchronise.
  

In a world of chaos, you just can't let go on discipline! But discipline must not be imposed on the team. The team must reflect on its struggles, understand the cause of their pains and agree on trying disciplined practices to provide scaffolding. This is another subject. For more information on continuous improvement, read this post.