An Agile Approach to adopting Agile

Several years ago, we started our quest towards a better way to develop software. In the process I discovered Extreme Programming or better known as XP. Though I liked many of the concepts that I was learning about, I definitely had my reservations on parts of it. However, the largest reservation I had was that it seemed that the founders and proponents of XP were requiring that this methodology was an "all or nothing" type of approach. If you didn't incorporate all of XP, you really would not benefit from the results that others have had with XP. In fact, some would say that you might actually experience worse results than Waterfall with a partial implementation.

This worried me greatly because I knew that past attempts of trying to implement an entire methodology had failed. Why? Too much to take on too fast. What I found interesting is at least for XP they were taking a Waterfall approach to adopting Agile. Instead, why not take an incremental and evolutionary approach to the adoption? Start with the highest priority items, incorporate them, get feedback on their adoption, and made improvements as needed. Continue this process at a pace that your organization can handle. Ultimately deciding how much agile is enough for your organization at any point of time.

At the same time this was going on, I had an interesting discussion with a colleague. He had told me he hated the idea of methodologies. Why? Because it makes the assumption that you can go buy a tool belt full of tools and assumes that you will not only use all of the tools but will know which tool should be used for which purpose. His approach? Find the tools you need that resolves the issues you need when you need them. To better find the tools you do need to spend the time understanding what tools are available and how to use them. However, it is important to note that knowing and using are two different things. Just carry the minimal tools that you need to get the job done. His approach was much more Agile in my opinion and one based on adopting a set of Best Practices than adopting entire Methodologies.

I eventually found the answer to our problems. One of the "founders" of Agile, Alistair Cockburn, had a "methodology" called Crystal Clear. Unlike others, it really wasn't a methodology but a discussion on what practices are available from XP, Scrum, FDD, and others. He truly advocated the "cut-and-paste" approach, find something that is close to what you need and put it into your own processes. Then, make it your own! He also advocated the incremental approach, at least start with SOMETHING than it will take a life of its own. He focused more on educating the reasons behind each of the practices, and being able to sell it to others through your own adoption.

This approach allowed us to explore all other methodologies as Best Practices to find the right set of tools for our tool belt at a pace where it can be learned and truly understood. If you are struggling with Agile, chances are you are going too fast and taking on too much. Slow it down and take the Agile approach. Do only the minimum of what it takes to address the highest priority issues you are dealing with. Then tackle the next one, and the next one, and so forth.

What's funny is that the founders of each of these methodologies took the same approach. They started out with something, then realized that something else was needed until they came out with a set of "somethings" that worked for their particular situation. They found a pattern as they continue to implement in different companies, and thus they developed their particular methodology. They took the incremental and evolutionary approach. They customized it through constant feedback and changes to make it work for them - for their cultures, their people, and the technologies and products they were developing. You have to do the same thing in your journey towards adoption!

Though this approach, we have grown to appreciate what each of the methodologies bring to the table. However, we had to learn what we were missing to truly appreciate what we could get with each of the Best Practices. In other words, we had to realize that we needed a particular tool to accomplish the job much better than the tools that we currently had in our possession. Bottom line, most implementation of processes fail because of lack of understanding. Either understanding of why they are valuable or understanding of how they can be used for your particular needs. If you don't know how to use a hammer, and you don't know why you would use a hammer, you probably aren't going to find the hammer that useful. Think about that for a moment!