I had a very interesting conversation on the scrumdevelopment yahoo group this week that really got me thinking about a few things. The argument was about the value of estimating stories in scrum. I will definitely talk about that in another post, as Ron Jeffries has once again opened my eyes to a new way of looking at things. What I really got out of this was a reminder that we need to sometimes go back to the beginning and cut out some of the cruft that has been growing in our understanding.
What was it that we liked about Agile when it hit the scene? The emphasis was on working software, not documentation and reports. The focus was to make something of value, release it often, and build the value incrementally.
What am I talking about? I’m talking about going back to the beginning of the Agile movement, even slightly before there was an Agile movement, and remembering why we are doing this in the first place.
I still recall how I got started “doing Agile”. I had just finished spending $30,000 getting my team trained in a semi-iterative, semi-waterfall process that was all the rage at the time, and still has quite a few adherents. I came away from this week feeling rather deflated and very disappointed. After spending all of that money, and having my team sit through a week of being lectured at, I started to despair that there just isn’t a good way to overcome the inherent problems with software development. As a side note, there was also an extremely heavy push by the teacher that there really is no way to use this process successfully without spending a ton of money on his tool. I remind myself of that whenever I go to coach a client.
So what happened next you are wondering…maybe. Well I’ll tell you. I went to visit another software shop, with an eye to maybe working there. What I saw was an incredibly happy work environment. People were working together, and they seemed to enjoy themselves. When I commented on this, they said that a large part of this was because they were doing Extreme Programming. The code was extremely high quality, they had predictable delivery, and even more interestingly, there was a high level of energy that suffused everything they did. This caused me to take a close look at what XP was all about. I was then able to try it in my shop, with a team that was curious but a little suspicious. I asked them to try it, and the results were fantastic. We had the fastest turnaround and the lowest defect rate of any similar group within our corporation. And most importantly, the team was having fun. One experienced programmer came to me one day and said “Steve, I just wanted to thank you for making programming fun again.” After ten years, I still consider this my highest achievement.
So lets go back to the beginning. Lets remember why we want to “Do Agile”. We want to create great software, and we want to enjoy ourselves while we do it. Take a look at your current process, and ask yourself, “how many of these activities are we doing because they enable great software, and how many of these activities are really there because we read somewhere that they are required?” I for one am going to focus on Doing the Simplest Thing That Could Possibly Work, with a side helping of You Aren’t Going to Need It.