This article presents how to lead the transition to an Agile process.
This article is based on Chapter 1 of Becoming Agile, to be published in May 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book’s page for more information.
Many companies try to “shotgun” agile into their organization. They think, “Let’s get through the migration pain quickly and start obtaining the benefits as soon as possible.” We’ve seen a few cases where this approach makes sense: for example, a project team that has become so dysfunctional that they’re delivering practically no functionality or business value. This approach also works well for a start-up company that hasn’t yet established its development process. But for most companies, you should allow time for the process to “bake.”
This is why we suggest an iterative approach for bringing agile into an organization. An iterative approach allows you to see how well your employees are adapting to the change. It also lets you learn what works and what doesn’t in your environment. In effect, it allows you to reach the right level of agility for your organization.
Part of your iterative approach will include a process for maintaining the methodology. We suggest establishing a core team to support this maintenance. A core team is composed of employees from all aspects of the development process. They play a huge part in establishing your custom methodology and then settle into a maintenance mode with the goal of constantly adapting to your environment. The core team is covered in detail in chapter 6.
Next, you need to choose the best way to iteratively create a methodology at your company. Should you select a packaged method, such as Scrum or XP? Or should you create a custom or hybrid process?
Custom Provess or Packaged Method?
In order to be successful, you should customize your agile process. For many years, consultants and others have said that you must embrace agile completely or not at all.
In 2006, we witnessed a shift in this attitude. Highly respected folks such as Kent Beck (the founder of XP) and Steve McConnell (the writer of Code Complete) now endorse customization. Kent Beck noted the following in an interview with InfoQ (InfoQ.com is an independent online community focused on change and innovation in enterprise software development) in 2006:
Failure at an organizational level seems to come from the inability to customize processes and make them their own. Trying to apply someone else’s template to your organization directly doesn’t work well. It leaves out too many important details of the previous successes and ignores your company’s specific situation. Rubber-stamping agile processes isn’t agile. The value of having a principle-based process is that you can apply the principles for an individualized process for your situation and, as an extra bonus, one that has been designed to adapt from your learning as you adopt changes into your organization. It’s always “custom.”
Kent’s quote is comforting to us because it supports our personal experiences. Custom means picking and choosing the agile practices that best support your environment. Custom means you shouldn’t use a pure packaged methodology off the shelf, such as Scrum or XP. You can start with one of these methods as a basis for your process, but you should modify it to obtain the best results for your company.
If we revisit VersionOne’s 2008 survey, we see that 14 percent of the people who responded are using a hybrid process based on Scrum and XP. The hybrid model is closer to what we’ll suggest for you. To be specific, here are the steps we’ll walk you through as the book continues:
1. Assess your organization to determine where you should begin adding agility.
2. Obtain executive support for the move to a more agile process. You can use the readiness assessment in chapter 4 to quantify the value of bringing in agile and identify the risks you must manage during migration.
3. Get the development team involved in the migration process to ensure buy-in. You do this by establishing a core team.
4. Identify a coach or consultant to help you with your migration. They will train the core team on agile and help you with other adoption aspects.
5. Develop a clear understanding of your current processes by documenting them.
6. Review your current process, and look for areas that can be shifted to more agile methods. Focus on areas with the most potential for improvement and the most value to the customer and your organization. The readiness assessment will also help with this task.
7. Outline a custom process based on the findings in step 6.
8. Try the new process on a pilot project.
9. Review the findings after the pilot, make changes, and continue to scale outyour new methodology.