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 the accountability that comes with being a decision maker. To many folks who thrive on 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 that the 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 this environment, our people will learn and grow in their ability to deal well with making 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 your staff 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 our organization, given our culture, customers, projects, tools, processes and staff. Armed with this information, we can evaluate each Agile practice against our 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 something that might have worked in some other organization. We want to adopt what will work in our company. We want to do the right thing so we can achieve our goals in this adoption, and improve our ability to do a good job of building good software.
Originally published in the Spring 2006 issue of Methods & Tools