Agile Development - Understanding

Another entry on my role as agile coach. My last entry on this subject told what happened when I looked for management support to help solve an internal problem. It wasn't a surprise when the management support was not forth coming.

The problem was that some team members did not understand XPs approach to design, and as a consequence were adding technical debt to the project at a rate of knots. Worst still, they did not accept my authority.

What to do? Well in a last ditched attempt I called an impromptu brown-bag session on agile design, and the cost of change. I described the need to "flatten" the cost of change curve when performing agile development, and I used examples from the project to make the point. The session was discussion based, with members of the team asking questions and offering opinions. It became clear very quickly that the team members that were hostile to TDD just did not have an appreciation of the cost of change, never mind how best to address it.

During the meeting I could see knowledge transform into understanding. They had heard the terminology before, some had even skimmed "XP Explained", but this was the first time that they actually understood.

After the meeting, members of the team who had previously said that "they knew it already", asked to borrow my copy of "XP Explained". There is evidently a big gap between knowledge and understanding. Perhaps I should of held the brown bag earlier. Yet I have a feeling that without the pain that the team went through, the less experienced would not have understood. Knowledge and experience leads to understanding. Knowledge on its own is not sufficient.

Consequently my authority in the team has increased. The doubters, doubt a lot less, and are more willing to take my lead.

Thinking through the lessons learned, I've concluded that this episode demonstrates a weakness in XP. How do you ensure that the less experienced developers do not cause too much harm. Especially if they feel that "they know it already"? XP provides no guidance other than to avoid inexperienced developers. I've been reading Crystal Clear - which provides a pragmatic solution to this problem. Let them do non critical tasks, like bug fixes and maintenance.

This idea brings us back to where we started - managing people. As a leader I need to be recognised as such and empowered, but XP does not stress leadership.

In fact XP provides little guidance on people issues. In some ways I find XP a bit de-humanising, reducing software development to a set of rigid disciplines. In contrast, Crystal Clear takes a more people centric approach. I can see myself borrowing from Crystal Clear in the future.