This is a continuation of the post Creating Trust in Agile.
Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements. Yet far too many technical managers see this as unnecessary hard work--and then they wonder why their projects end up unsuccessful.
Forget the jargon of "sprints" and "iterations." Communicate in your stakeholder's language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective?
Mind you, this is probably good advice for 90 percent of IT and technical projects. The challenge facing AAs is they don't have detailed plans and traditions specifications to benchmark progress against. New ideas need to be developed.
AAs should also create ways of managing and reporting risk, scope, cost, time and quality--not from the technical in-team perspective but from a senior management perspective.
The essence of Agile is flexibility and change. The traditional way of dealing with these issues is by measuring the current variance from a predetermined baseline. The issues are no less important in Agile. They just have to be managed and reported differently. The challenge for AAs is developing effective ways of communicating how they are being managed to their senior management.
Finally, AAs need to have ways of differentiating problems suitable for Agile solutions from those that need a different approach. Agile is not a cure-all for every project and problem--senior management knows this and AAs need to focus on areas where real value is created by the methodology.
I'm not an AA. So I'll leave it up to the Agile community leaders to work out a solution ...
Over to you for comment!