Trust--backed by skilled developers--is the core element of any Agile methodology. Within the project team, the trust is relatively short term and the model is trust, but validate.
The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership.
Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time.
The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt.
An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end."
With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches:
We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value.
We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way.
In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline.
To be continued ...
Editor's Note: This post is part of a continuing discussion on Agile. View Lynda's recent entries.
The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership.
Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time.
The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt.
An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end."
With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches:
We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value.
We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way.
In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline.
To be continued ...
Editor's Note: This post is part of a continuing discussion on Agile. View Lynda's recent entries.
I believe in the saying you can only give what you have.
Lead by example. A PM needs to trust each member of the team in there respective role so that they can trust in the direction a PM takes.
If leaders don't invest in trusting the people under them, then failure starts. The key is diligence in every activity of the project, small or big.
This reminds me of the older generation of craftsmen carpenters. They described their projects as mostly about the quality and the detail. The exquisite detailing in Victorian and craftsman style projects in California, With Birdseye maple butterfly dovetails in rich mahogany casing. Or the hand made stained glass lighting.
I have been able to work on a few cherished projects in which the projects were not spelled out in terms of parametric estimating but in terms of trusting the craftsman to do whats right.
I think there is a pendulum that swings back and forth. We want to provide trust to people to develop exquisite details, but with all the Madoff's in the world it is not feasible.
Hi Lynda,
Thank you for this interesting piece of thoughts.
High management is faced with a conundrum. On one hand, should they trust teams and people who have failed to deliver in the past, just because they are now adopting a different (Agile) methodology? On the other hand, should they trust the total strangers that are Agile consultants?
That's a difficult call!
Does the answer lie in serious project management discipline as you suggest? Or, as you pointed out in your first sentence, competence from skilled developers?
And what about transparency?