I thought I understood the whole “agile thing”. I’d read Test Driven Development by Jim Newkirk and thought I understood it. Turns out when I attended a seminar on TDD I really only got about a two thirds off the stuff I’d read in the book. Since then I’ve done some paired TDD programming and discovered even more that I’d have never have picked up on my own. All this by talking and doing with more experienced practicioners of the art.
I read Ken Schwaber’s Scrum book, among others, and thought I understood that. Again, I did Ken’s course and learnt a bunch more things I thought I already knew, but either didn’t or had misunderstood. Again, when I went back to my product unit to run my first Scrum team I thought we were doing a reasonable job. That is until one of my mentors said “what you’re doing here is waterfall with daily standup meetings” – he was right.
In both cases I don’t think it’s because I didn’t understand the concepts or wasn’t willing to try them. Exactly the opposite was true; I was psyched to try them. It simply turns out that they are hard to describe and even harder to put into practice, especially against a background of ingrained practices and beliefs that run counter to agility – both in me and my co-workers. There’s a huge cultural change involved here and it requires a lot of time and energy to get right.
I underestimated the amount of time, effort and experience required to instigate these changes. People will tell you that forming an agile team is hard. What they can’t tell you is how hard it really is. It is way harder than you think it will be. Perhaps ten to a hundred times harder! You need lots of help along the way. Doing this without mentors and coaches is simply making it harder and increasing your chances of failure or, at best, partial success.
I found that agility, whether it be Scrum, XP or something else, isn’t something you can easily learn from books or courses. You can just give a team some books and then expect them to go do, say, Scrum. It’s very easy to think you’re doing something right when actually you’ve reverted to the old way of doing it, it requires continuous monitoring of the team by knowledgable mentors to stay on track. In this respect it’s not like learning to ride a bicycle. When learning to ride you get direct feedback when it’s not working – you fall off. When trying to do agile software development the only way to get this sort of binary “falling off” type feedback is by surrounding yourself with people who can tell you when the team is falling off the agile bicycle.
The best way to understand what it means develop software in an agile way is to do it with people who’ve done it before and both failed and succeeded. Compose teams from people who want to try change and include on those teams people with previous experience. Surround those teams with mentors with time to focus on helping those teams form and ultimately be successful.