By George Pitagorsky | Follow on Twitter!
Agile is still a controversial subject in project management circles.
"Who wouldn't want agility?" You might ask. When I think of agility I think of an elegantly flowing healthy process, effective, open to change, adaptive, clear headed. If agility is such a good thing, then why the controversy?
Part of the reason is a misunderstanding of the basic principles of agility. The Agile Manifesto articulates those principles as a set of values:
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."1
These valued items are critical factors in establishing an effective approach to performing projects of any kind. Even more critical, is the implications of the last sentence. It represents a way of thinking, a bit of wisdom, that does away with unnecessary conflict, and not only in the question of agility in projects. The wisdom is Both-and thinking. The implied value is open minded acceptance of the real nature of projects.
Either-or thinking is a curable disease. Either-or, black and white, thinking is so widespread that it has become an accepted norm. It is a thinking habit for many people and, in particular, for people with crisp analytical minds – the kind of folks who tend to be engineers, business analysts, finance professionals, project managers and software developers.
Either-or thinkers see the world in concrete terms with firm boundaries and unambiguous, black and white, answers to even the most complex questions. It has to be either this or that. Uncertainty and imprecision cause stress in those with low ambiguity tolerance. Rigid boundaries and unambiguous answers are comforting.
But, the world is not all black and white. Boundaries are man-made conveniences and, with or without walls, subject to change. The more complex an issue, the more likely it is that there will be shades of gray.
Continuums and Both-and Thinking
Continuums between alternatives and hybrid solutions abound; they are the norm. Continuums are made up of an infinite number of positions between extremes. The bipolar, either-or view sees delivering code or documenting; collaborate or contract as mutually exclusive.
Both-and thinking is the cure. Either-or thinkers who open to the probability that one approach may not be particularly better than another and to the need to think in a collaborative, Both-and way are immediately cured. They may have remissions from time to time, but if they remember continuums and the power of an open mind they are cured again and again.
Let's look at agile in this way. The founders do not say "don't document" or "don't plan" - they don't advise against contracts. They advise us to remember our primary goal - deliver a project outcome that satisfies stakeholders and meets their expectations.
Agile must be applied in a way that addresses the needs of the situation.
In a project to automate a new algorithm for equities trading, programmer analyst and trader are paired and work interactively to conceive and develop. There is no documentation other than the code and notes. No explicit written contract was negotiated. The relationship between the partners is key to success though, with agility, the programmer analyst brings process into the mix, subtly and flexibly. They don't talk about Agile, waterfall or hybrid approaches. They just get together and do the work.
In a program with 50 direct participants representing several thousand stakeholders, to implement an improved enterprise-wide business process, there is need for scope documents, charters, requirements definitions, test plans and more.
Working with vendors, well negotiated, legally binding contracts are necessary. Working with busy functional groups that serve multiple clients, there is need for a memo of understanding or statement of work that defines the terms of the engagement. Without these “contracts” there is a high risk of unmet expectations and conflict.
The more complex the project, the greater the need for process, documentation and contracts. But, that doesn't rule out agile.
There are collections of small projects within the most complex programs and projects. For example, developing a website in the context of a broader initiative. A project like this can be addressed in a highly agile way, with a very high level statement of requirements and scope and a core team that works together to evolve the web-site in a sequence of sprints.
The scope statement is both a starting point and a constraint on scope creep and a never-ending effort. The "contract" may be informal, though business analysts, programmers, web designers, marketing people and representatives of the user community must agree to a process, and commit time and effort.
The bottom line: regardless of the approach you choose,
- Be open to the need for situational management, to adapt whatever approach you choose to the needs of your specific project in your specific environment. Adhering to a management philosophy or a special methodology may have its benefits, but in the end, if you are not taking corporate culture, the capacity of the individuals involved and the costs associated with more or less formality, you are likely to fail to work optimally.
- Remember your project goals and objectives and deliver useful outcomes. Sponsors and clients tire quickly of interim deliverables like requirements documents and designs that are not quickly followed by deliverables that clearly bring business value. At the same time, your product will last for a long time, will there be sufficient documentation to support it. Will there be enough formal documentation of requirements to avoid unnecessary conflict and disappointment?
- Don't get caught up in analysis paralysis or uncontrolled scope creep - follow an effective process. Agility and analysis coexist and reinforce one another. An agile approach enables action to create and deliver frequent tangible results. Analysis figures out what is best to deliver and how to do it.
- Cultivate and maintain healthy relationships with or without formal agreements. When people work together there is always a contract, even when it is unstated. Everyone has expectations. It is a best practice to bring them to the surface and make sure they are mutually understood, realistic and in-sync. As you are doing that apply your ability to be diplomatic, open minded, a good listener and all the other behavioral skills to make for a healthy relationship.
Questions or comments? Feel free to share them below!
You may also like:
ABOUT THE AUTHOR: George Pitagorsky, PMP, integrates core disciplines and applies people centric systems and process thinking to achieve sustainable optimal performance. George authored The Zen Approach to Project Management and PM BasicsTM. He teaches meditation and is on the Board of Directors of the NY Insight Meditation Center.