Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.
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 ...
One should be an advocate of the right solution for the right context.
Projects where there is a great deal of uncertainty regarding what you are going to build and how you are going to build it are the best candidates for Agile (from Ken Schwaber). I've been a very successful Agile advocate, and I start by understanding the nature of the projects people are working on and what they are struggling with. I use that to make recommendations. I completely agree that Agile advocates need to speak to their audience's needs, not Agile jargon.
I have a couple of blog posts regarding Agile advocacy on my blog that viewers of this might find relevant. http://www.enagility.com
I agree that Agile Advocates need to understand their stakeholders and empathize with their perceptions, fears and requirements. However, this is not just an Agile issue, all project teams need to do this to be successful, agile or not.
I also agree that jargon, whether â€œSprintsâ€ and â€œIterationsâ€ or â€œCrashingâ€ and â€œHammock Activitiesâ€ (these last two from the PMBOK v4) hamper rather than help communications and should be avoided if everyone is not familiar with the terms. Technical terminology can be an efficient shorthand for those who understand the terms, but a source of confusion and an unnecessary barrier to entry for those who are not accustomed.
Agile methods have developed new ideas for describing the benefits being delivered and how they can be measured. Contingencies and progress from a business perspective are covered also. Here is how: IT projects often face levels of requirements and technical uncertainty that make accurate upfront planning difficult.
When the project terrain is uncertain like this, measuring progress against a likely flawed plan is not in the project team or sponsors best interest. Questions such as â€œAre variances due to project deviations, or was the initial plan incorrect?â€ are common.
Agile projects attempt to avoid these â€œis our map wrong, or are we heading the wrong way?â€ debates by instead working more closely with the business to outline all the business functionality that needs to be completed before the project can be declared done and complete. Then progress is tracked against this list of agreed functionality.
Progress is reported in terms of business items completed vs business items remaining. This way, progress from a business perspective is very apparent. This approach is not without challenges, technical dependencies still complicate matters and breaking work down into similar sized chunks or assigning scores to facilitate tracking has become a complicated science and the subject of many books. However, progress is tracked in chunks of functionality that the business can understand. For example â€œThe Product Report by Regionâ€, or â€œInventory Detail screenâ€ might be the types of work items tracked. Granted, not all stakeholders may appreciate the value of these items, but I would argue that they are closer to real business concepts than reporting that the Data Model is 30% complete. What does that mean? As a business sponsor, I may not be aware that a â€œData Modelâ€ was even on my shopping list?
In reality the successful agile projects I have seen do not abandon the traditional concepts of planning, tracking, or any other PM concept. Instead they introduce a set of complimentary tools for undertaking projects with increased uncertainty. Where tracking to a baselined plan is problematic, collaborating with the business on a prioritized feature list has been found to be effective. Estimates to complete can be calculated by examining feature completion speed and extrapolating progress across the remaining features. Contingencies can be incorporated by allowing for a % of time for new feature discovery or adjustment of projected completion speed.
Agile methods work extremely well for projects with requirements and technical risk. Tracking and reporting in business terms is actually a strong point of the approach. I agree jargon is impeding adoption and this is a shame, â€œrolling wave planningâ€ and â€œprogressive elaborationâ€ (PMI terms many traditional project mangers are sometimes unaware of), are actually very well aligned with agile concepts.
I am hopeful that the PMI Agile group can help strip away or at least explain the jargon and share with a wider audience approaches that are effective in challenging project environments.
Lynda raises an interesting point that may be addressed by the agile principal of delivering working software.
"... what benefits are being delivered and how can they be measured? ... What real progress is being made from the business perspective?" This is largely addressed with traditional cost/benefit analysis and ROI measurement techniques.
Presumably, the features defined at the start of an iteration have some expected business value. Ideally, upon completion of the iteration, the software should cause a change in some business metric and the benefit of the software is measured by the magnitude of change. In the less ideal world, few businesses actually measure business value, so before and after comparisons are largely subjective.
"What contingencies are in place?" By working in iterations, the at risk cost is minimized. Risks only need to be mitigated after they are realized. This helps reduce the costs from over-engineering to deal with potential issues.
"... ways of managing and reporting risk ..." The use of agile goes beyond managing risk and forces high risk areas to be addressed as soon as possible. The reporting of realized risk is a given in agile, as each iteration provides a hard and fast quality gate.
"... ways of managing and reporting ... scope ..." The planning phase of each iteration provides an ideal framework for a change control board and provides a structure that truly allows the prioritization of changes.
"... ways of managing and reporting ... cost ..." Agile changes nothing about reporting cost - it is still fixed costs plus labor hours times labor rate. For managing costs, each iteration provides a gate where future costs can be increased, decreased, or eliminated.
"... ways of managing and reporting ... time ..." The whole basis of agile is about time-based management. Agile relies on on delivering within time constraints.
"... ways of managing and reporting ... quality ..." This is a challenge under any approach, but by using frequent deliveries of working software, agile allows product quality to be measure in business terms, trends tracked, and aberrations quickly addressed.
"... ways of differentiating problems suitable for Agile ..." This is really a strawman argument, because it places a bar for agile to clear that other approaches have not been asked to address. The true issue, I suspect, is not in the nature of the problem to be addressed, but in the nature of the organization addressing the problem.
Agile speaks very well in the language of stakeholders. It provides an unambiguous answer of "When will it be ready?" and addresses hard and fast deadlines.