Originally Published on allPM.com
The Buddha spoke of tuning a stringed instrument. Too tight and the string breaks, too loose and there is no music. Our processes are instruments that need to be tuned for optimum performance.
Agility
Agility is the ability to move with speed and grace; to be nimble.
What is the minimal activity to get the job done well? When we can answer that question we have the base for an agile process - a process that is quick and graceful because it has no excess and one that does what it is designed to do because there is no insufficiency.
Some PM experts refer to this as an informal process.
I prefer agile.
Formality is necessary.
It does not preclude agility.
We need to be both formal and agile.
Just agile isn't enough. Formality gives structure and direction to agility.
Too much formality and we have excessive overhead and performance barriers.
The Agile Alliance (http://www.agilealliance.org/) has a Manifesto for Agile Software Development we can apply to project management. But, before we apply it, the manifesto needs some polishing and reorientation in the opinion of this writer. As it is written, there may be a tendency to promote division rather than consensus. Let's explore the manifesto.
The manifesto says:
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more."
Pitagorsky's Zen approach seeks dynamic balance. How much more valuable are the left items than the right? Even though the last sentence in the manifesto tries to bring out a need for balance, some tend to think in absolutes and are apt to throw the baby out with the bathwater.
The Zen approach has us look at the total picture and not get lost in conflicts. The big picture view turns conflicts into resolutions. First we recognize a continuum between left and right and then we can add some objective criteria to make it easier to manage balance within the continuum. In the next few paragraphs we will dig a bit deeper into the Agile Manifesto and see how it can be reconstituted using the Zen approach.
Individuals and interactions using processes and tools
In the Zen way we see process and tools as means for enhancing the effectiveness of individuals and interactions. The process and tools must be flexible, with the minimum amount of overhead and restrictiveness to satisfy the need for control and consistency. Individuals must be empowered to creatively adapt. They must be motivated to communicate and collaborate. For example, a process for naming and controlling documents combined with a tool for document management and collaboration support would make individual effort and interaction more effective. Allowing everyone to do their own thing can lead to confusion, unnecessary rework and conflict.
Working software and comprehensive documentation
If comprehensive means all the documentation that is needed, then why value it less than the product itself? Software is an example. We could be talking about any product. A working product may be useless without comprehensive documentation. Consider the pharmaceutical company that had a good working product but could not sell it because there was insufficient documentation to satisfy the regulators.
Documentation without the product is probably more likely to be useless than the product without documentation. I can't think of anyone who wants the documentation for how to work a new appliance without the appliance. We need the working product itself and the documentation. In fact, the documentation is part of the product.
Of course, delivering more documentation than is necessary to satisfy business and customer needs is simply not clever. Why spend more than is needed? The goal is to deliver the right documentation. Not too little. Not too much.
Customer collaboration through contract negotiation
As for customer collaboration and contract negotiation, aren't they one and the same thing? Whenever we collaborate with a customer we are creating a contract - implied or explicit, legally binding or not. The contract (you may call it an understanding, agreement, service level agreement, letter of understanding, or whatever you like) states the expectations that bind the parties.
If negotiation becomes divisive, then get better at negotiating. In project management as elsewhere, win-win results support and result from collaboration. Both the absence of written understandings and rigid adherence to the letter rather than the spirit of the contract detract from collaboration and lead to unnecessary conflict.
Responding to change while following a plan
Lastly, there is the matter of responding to change rather than following a plan. Can we follow a plan and respond to change? Of course. But it is clever to be concerned that blindly following a plan will make responding to change difficult or unlikely. If the PM thinks following a plan means doing whatever the plan says without evaluating it in light of the present situation and never changing the plan, then there is a problem.
The plan, like a defined process, represents a baseline. Effective PMs recognize this and plan for change, enable positive change and inhibit unnecessary change. Positive change is change that is needed to meet project and business objectives in the face of progressive elaboration and understanding of those needs, changes in the marketplace, availability of resources and other aspects of the project environment.
The Need for Control
The Agile methods with their change-embracing philosophy have downplayed the need to control costs and schedules. The book, Planning Extreme Programming by Kent Beck and Martin Fowler, addresses the issue this way: "The customer wants to know what she is getting for her three hundred grand. Sure, she wants to know, but she can't know. Planning is not about predicting the future." This notion is found in other industries besides software.
Does that mean that the Extreme approach (a variation of the Agile approach) can control the costs or the scope but not both? If so, then it does not satisfy the customer. Maybe she can't know exactly what she will "get for her three hundred grand" but she should have a pretty good sense of it before she lays out the money. Sure, there are no guarantees, but for my "three hundred grand" I want a pretty solid idea of the expected outcome and the process for getting it as well as an update every so often about what I will really be getting and when I will be getting it.
The Agile Alliance says, "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." Sounds good but it does not tell us how to control costs and schedule. Nor does it tell us what to do about the wide variety of skill levels and motivation among the people available to perform the work.
While trust is a very important and worthwhile quality, we must be aware of the possibility that not everyone is trustworthy. I have learned the hard way that trust may be a sure way to disaster. Trust is based on experience.
Have the people done it before? Have they done it well? Do they have personal integrity? Are they ethical? Are they adaptive and creative or more likely to follow a prescribed path? Do they tend to act like two year olds, adolescents or adults? What is their Emotional Quotient and IQ? These are some of the questions that come to mind when I think about whether I can trust a person or team.
In PM as in life, trust is balanced by continuous evaluation of current performance within constraints. In the Agile Alliance's stance, "Give them the environment and support they need, and trust them to get the job done," does environment and support include controls and external management? If it does then we can trust the people to get the job done. If not, then we'd better think twice about it.
The Bottom line - Are business and client needs met?
In the end, the measure of success of the process is whether business and client needs are met. Client needs include quality, delivery time and cost as well as minimal disruption. Business needs include regulatory compliance, healthy customer relationships, risk management, cost control, profitability, and alignment of multiple projects and programs with strategy.
There is no cookbook, but there are defined processes that are cleverly engineered and can be used to rightly balance flexibility and discipline to enable truly agile and effective project management.
The Zen approach is founded on the non-dualistic concept that all things are unified within a single framework. While there may be opposites like good and bad, hard and easier, etc., they are the end points in continuums rather than discrete positions. There are no absolutes in our relative world, as individuals coming together in groups to work and play. As soon as we try to define Agility as this over that, we run into trouble. People become entrenched in their positions and unproductive conflict arises.
Find the right place on the continuum, for each moment. This is among the most critical skills of anyone, PMs or not. How do we find that right place and then be unattached to it to maintain balance in the face of an ever changing environment? The tightrope walker doesn’t think about shifting his weight or taking the next step; he just does it. Similarly, we embody the rules, guidelines and formal learning and then we let go into the work, trusting in our experience and skill.
© 2005 allPM.com
