Agile attraction and inexperienced teams

I suspect that many teams are attracted to agile development methods because it is simple to explain the methodology and understand. Some of these teams may be just inexperienced, some may be in organizations that are under extreme stress to get something done quickly or they will go out of business or be dissolved.

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.

Tailor at your own risk

I signed up to speak at the next Cincinnati SPIN meeting next week. I plan to talk a bit about adapting agile methods such as SCRUM to work in distributed environments. Or just tailoring your current methods to introduce some agileness. I have a fair amount of anxiety on this topic.
What I fear is encouraging people to pick and choose from a set of Agile methods and then get in deeper trouble or further spread misconceptions. I believe processes like Scrum are the result of considering a particular development scenario and then putting it through a lean process filter. The outcome is a small tight set of processes where nothing is optional. (retrospectives, user stories, close customer collaboration, etc. ) Where some one to cherry pick a few of those processes and then claim to be doing Scrum it could be a big problem. Hence I think the difference between SCRUM and agile is like the difference between a set of values and a coherent integrated set of processes. Values are more abstract and processes are more concrete. It is like democracy and the government system of a particualr country. Agile is to democracy as Scrum is the the UK system of government.

On the other side of the coin I consider the multiple places I have worked or served as a process mentor and despite what ever label they apply: RUP, extreme programming, FDD or scrum there are still considerable variations among groups the profess to be following the same process. I believe that we tend to believe that things are more alike than they really are for groups who profess to be following a certain process. We under appreciate the tacit and implicit customizations that each group adopts. These adoptions are critical success factors.

Bottom line there is no magic bullet best practice. The art and science is in the tailoring and adaption of the broad range of best practices as identified by SEI or PMI with a values foundation as expressed in the Agile Manifesto. People over process, working software over extensive documentation, etc. Think like an agilest but make sure you have a story for dealing with scope management, risk etc.

I thought I was pretty smart 10 years ago when I had 20 years of experience. Now that I have 30 years of experience I realize how difficult this is and I have even less confidence. What I do appreciate is the wisdom I draw from all schools of thought and bodies of knowledge. Comming up with the most appropiate development and project management process is a very challenging endevor. The good news is there is now a lot of wisdom to draw from. Good Luck.