As I mentioned in a previous blog, on my current contract I have been performing the role of Agile Coach. I'm not sure that i'm a natural fit for coach, but the project desperately called out for Agile practices, I was the one with agile experience, so I was made coach.
On my previous project, I had the great fortune to be coached by Rachel Davies. Rachel is a very well respected member of the agile community. She is the chair of the extreme Tuesday club in London (www.xpdeveloper.com) and a director on the board of the agile alliance (you know the people that wrote the agile manifesto: http://www.agilealliance.org/home, people like Kent Beck, Martin Fowler, Bob Martin etc). In the Agile community you can't get better credentials than this. Racheal really impressed me in the way she assisted our team in coming to the right answers for ourselves. Never telling, but patiently observing, taking notes, pairing with individual members of the team, and providing input in the most subtle ways. In short Racheal demonstrated a very high level of skill.
In contrast, I'm more of a teller and a doer, not that good at observing and influencing, but inspired by Racheal I resolved to do my best in my new role. Interestingly, my immediate successes where with the Management. Within a short time I was able to demonstrate the power of user stories. The technical management had been having a difficult time in defining the requirements with the users and avoiding scope creep. They where quick to appreciate how stories would help.
Soon we where up and running, boostrapping the XP process by initially writing stories ourselves from the technical specs. We then introduced stories to the testers, who where quick to get on board after months in the dark. The next person on board was the user. He found seeing what he was getting and defining priorities a massive improvement. So much so he cleared space in his diary to be with the team 3 days a week.
The people that proved most difficult to influence was a, the business analyst and b, the developers. The response of the business analysts was somewhat expected. These people have a vested interest in producing paper specs that everyone knew had limited value. We needed to tread careful, coaxing the BAs into realising that stories could be good for them too. Even with the BAs we have had some success, with one or two of them being quite keen to write stories instead of continually revising specs.
The difficulty with the developers came as a great surprise. Some members of the team initially found it extremely difficult being told what to do. I believe the phrase don't teach me how to suck eggs' was quoted more than once. I had to go to great lengths to stress that I was merely identifying an alternative way of working, which in no way invalidated the way they had worked in the past. The experienced developers were quick to see the benefits of XP practices even though the practices were not familiar in themselves. The less experienced developers in the team however, found it more difficult to see past what they already knew. For example, TDD is still seen by some as primarily a unit testing technique (as opposed to a programming and design approach).
NIH (Not Invented Here) and ego centric technical debates soon engulfed the team. Unnecessary complexity was added to the code base, and technical debt began to grow. Worst still I was in danger of becoming the main protagonist in these technical debates. People wanted to prove that I was wrong, and that they knew better. This situation called for swift action. I decided to take a back seat, stopped leading from the front and allowed the team to make decisions for themselves. That iteration no stories were delivered, instead people bussed themselves with technical tasks, making "improvements" to the core architecture.
After the experience of zero velocity, many in the team realised for themselves that Agile development required discipline. My next step was to clarify my role, by suggesting that we needed a technical lead. Fortunately we had a good candidate in the team, who was keen to take on the role. For a couple of iterations velocity soared under our new lead.
Now we are potentially weeks away from our first release. Unfortunately the technical debt incurred during earlier iterations still needs to be paid. It will be interesting to see how things work out.