Click here to view the complete list of archived articles
This article was originally published in the Spring 2006 issue of Methods & Tools
Adopting an Agile Method
Alan S. Koch, http://www.ASKProcess.com
Projects
Every project is unique and represents unique challenges and opportunities. Nonetheless, most organizations tend to take on projects thathave a relatively predictable set of attributes. Some companies do mainlyfinancial and administrative systems. Others do real-time embedded systems. Whatkinds of projects to your development teams generally work on? The types ofprojects that your teams take on have a certain amount of uncertainty to them.They represent a certain risk profile. And they include a certain amount to technological innovation.
Although the Agile methods were mainly developed to meet the needs of small projects that expect significant turbulence and change, they can also be used in many other kinds of environments. Most of the Agile methods expect that the development team can work face-to-face on a daily basis. If this is not the case in you organization, then some of the Agile practices may need to be modified to work with a distributed team.
The promoters of the Agile methods tell us that their methods can and should be used on any project. Indeed, some of them are experimenting with Agile distributed teams. While it may be true that Agile methods can be used on any project, the questions you must ask is, should you use the practices these methods prescribe on your projects!
This means going back to the purpose you identified for adopting an Agile method, and determining if the practices will support achieving those goals. Examine the practices that you expect to adopt, and for each, determine the extent to which it can be implemented given the realities of your projects, and the benefits you anticipate can be reasonably expected to accrue.
Tools and Processes
The methods we employ do not exist in a vacuum. They are strongly influenced by the environment in which we use them; and an important part of that environment includes the supporting tools and processes that we depend upon.
As things stand today, your organization already has a set of tools and processes in place. To what extent will those tools and processes be compatible with and support the new Agile practices you expect to adopt? Will your processes and tools (e.g. for requirements management, or for Quality Assurance) stand in the way of adopting Agile practices? And if so, is there latitude to change them (or get rid of them) in order to make the environment more conducive to the Agile practices?
The flip side is also true. Many of the Agile practices require specific tool and process support in order to be effective. For example, eXtreme Programming expects that automated testing tools are available to the entire programming team, and that they use them heavily. Are such tools available in your organization? And if so, are there enough licenses to allow this widespread use?
Another example is code control tools. Most of the Agile methods assume strong code control systems and strict adherence to the disciplines involved in using them. Liberal use of things like refactoring and shared ownership of code can only work in an environment that provides the necessary code control tools and processes.
Examine the practices that you expect to adopt, and for each, determine the extent to which it can be implemented given the realities of your tools and processes, and the benefits you anticipate can be reasonably expected to accrue.
Staff
As we noted earlier, the Agile methods expect that development teams will be self-directing. This means that instead of being told what to do, the team understands the objectives of the project, and they collaborate with the customer and each other to determine the most appropriate steps to take at each juncture.
In order to act autonomously, the team members must be willing and able to take on a new level of responsibilities and accountability. Although this may seem to be an easy step (based on the complaining we often hear from programmers), it is actually quite a leap to go from complaining about the status quo to taking on the responsibility for creating a new one!
Many of our programmers are not as bold as we might expect. They may have good ideas about things to change, but be unwilling to take on theaccountability that comes with being a decision maker. To many folks who thriveon technical challenges, the messiness of project and customer challenges can be quite intimidating.
And of course, our development teams do not represent uniformity in capabilities. Some of our folks are indeed super stars! But others'abilities are quite lacking. If we are honest with ourselves, we must admit thatthe average programmer on our teams is only average! And around half of them are below average.
The Agile methods empower teams to direct their own work (in collaboration with the customer). It is true that as they work in thisenvironment, our people will learn and grow in their ability to deal well withmaking project decisions. But how successful can they be at the beginning? And at what point will they reach their maximum potential?
Examine the practices that you expect to adopt, and for each, determine the extent to which it can be implemented given the realities of yourstaff today, and the benefits you anticipate can be reasonably expected to accrue.
Adopting an Agile Method
After we have considered all of the things we just discussed, we will be equipped to decide which Agile practices would be appropriate in ourorganization, given our culture, customers, projects, tools, processes andstaff. Armed with this information, we can evaluate each Agile practice againstour objectives, and determine which ones we should adopt, and if we need to customize them in any way.
In essence, we will be "rolling our own" Agile method. But isn't that what we need to do? We don't want to adopt somethingthat might have worked in some other organization. We want to adopt what willwork in our company. We want to do the right thing so we can achieve ourgoals in this adoption, and improve our ability to do a good job of building good software.