Speaking to a friend today we commented that there seems to be a increasing popularity of seminars, lectures, and classes related to some Agile agile method or practice. I fear a coming backlash or pendulum swing in the opposite direction as various folks pretend to adopt an agile method, get into some type of trouble and then blame agile as not living up to the hype.
My analysis is based on two fundamental beliefs. One, is the amount of formal process you need is inversely propositional to the experience and skill of the team members. Inexperienced folks need more formal process and very experienced folks need less process.
Two, an agile process will expose problems and issues with the project more quickly than a more traditional development process. What to do about those problems and issues is not always very clear for an agile team. The natural conclusion here is that serious consideration should be given before the leadership endorses the adoption of agile for an inexperienced team.
Now, but what about the adoption of agile for a team operating under stress. Perhaps that team is comprised of experienced people but due to some pathology in the organization such as "mushroom management", fear, mistrust, wide geographic distribution or some other organizational challenge. The folks on this team have a good chance of identifying what are the obstacles but they may run right into a brick wall. These walls are may often be "organizational constraints". They may be political or geographic obstacles that are beyond what any development methodology can overcome. Consider the following:
- A project sponsor that doesn't have the depth of experience to understand the challenges of a software development project.
- An organizational culture where there is rift between the users and the developers that has made mistrust and suspicion the norm for the last ten years.
- A team that is spread across 3 continents. The communication challenges make it difficult to exchange technical information or to even build a climate of trust and cooperation. With the Internet and modern collaboration tools it is possible to mitigate the challenges but not to eliminate it completely.
When a team in such a situation attempts to adopt and agile method under these circumstances failures can often be blamed on the Agile method. "It just doesn't work" or "I don't believe in things like that" is often the refrain. When in fact the failure is to properly consider the environmental and organizational factors. Identification of these factors is right out of the PMI PMBOK. Or consider the CMMI based discussions on tailoring of development processes.
My sense is the key is developing the guidelines and science to consider the "environmental and organizational factors" or the skill in tailoring a software process to a particular situation. Then we will come to view an Agile practice such as Scrum as a very nice development method but not a one size fits all solution for every development team. When going agile I'd look for heavy customer participation, high bandwidth interpersonal communication between the team members, and a organization where trust can flourish and grow.
