Maximizing the Value of Agile

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , , , , , ,
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.

About this Blog


View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina
Jess Tayel
Ramiro Rodrigues
Linda Agyapong
Joanna Newman

Recent Posts

Mix & Match

Agile Evolves

3 Tips to Enhance Your Leadership IQ

3 Tips for Becoming a Better Listener—and a Better Project Manager

Maximizing the Value of Agile

Categories: Agile

By Lynda Bourne

Everyone wants to “go agile.” But far too many organizations seem to think agile is simply a different way of doing project work that will miraculously achieve major efficiencies. 

For the approach to achieve its promise, the upper echelons of the organization need to become agile aware and adapt the way projects are initiated, funded and governed so that the project team can optimize their use of agile processes to create value. After all, one size does not fit every situation in an agile world.

I’d like to look at the differences in the management approach that are needed to maximize the value of agile in different situations.

One quick note: Different agile methodologies have different terminology and approaches. For this post, agile is defined as producing an output using a series of relatively short, time-boxed iterations, or sprints, where the work to be accomplished in each sprint is sized to be relatively consistent (e.g., can be accomplished by a team in two weeks), and what is to be done in each sprint is determined during the lead-up to that sprint.

There are three environments where the agile approach can add value:

1. Maintenance environments: In these efforts, the application of agile concepts without the need for project management overheads can be very beneficial. Techniques including small focused teams, short sprints, backlog prioritization, and management. Burn down reporting can show how much maintenance work is facing the teams, the team efficiencies, and the overall backlog trend.

Agile does not need to be embedded in a program or project to be effective. In this situation, the finance and resources (i.e., the agile teams) are the fixed constraints; the organization’s budgeting procedure funds a predetermined level of staffing on an annual basis. The management variable is the amount of work accomplished each month and deals with new and emerging maintenance issues and minor enhancements in a timely manner based on some effective form of prioritization.

2. Contractual or legal obligations: In projects like these, the scope of work is fixed (or at least subject to formal change control) and the management variables are efficiency and cost consequences. In this environment, with adaptation, a whole range of standard project management processes such as earned value can be applied to the oversight of project work and used for management reporting and project control. The agile teams still function in the traditional agile way, sizing the amount of work included in each sprint, producing usable outputs in short intervals and progressively building toward the completed project. The management challenge is achieving the specified scope within the approved time and cost parameters.

3. Projects that lack a defined scope: In these projects, the client often has a vision of what the outcome should achieve, frequently framed in terms of business improvements. In this situation, the project is on a journey to optimize the delivery of as much of the vision as is sensible. The management variables for this type of project include scope, cost and time.

Decisions will have to be made about which parameters are more important—either as an overall consideration or on an element-by-element view of the various components within the project.

a. In some projects, time to market is a key factor, possibly with scope as the second most important factor. And, to a large extent, how much it costs to achieve the necessary scope within the deadline will be a consequence rather than the control. The primary management challenge is delivering the scope required to implement the vision within the time constraint as efficiently as possible.

b. Other projects have the quality of the vision as their primary drive, and the management challenge is to achieve all of the vision for the optimum time and cost outcomes. Decisions on how much and how long can vary depending on progress toward achieving the vision. Obviously, there must be some cost and time constraints. And a key conversation with the client has to be around the value proposition of still achieving their vision based on cost information to date, with the possibility of adapting the vision based on learned experience as the project proceeds.

c. Lastly, in some projects where the available funds are limited, the challenge for management is to achieve as much of the vision as possible within the defined funding limit, frequently with time as an additional limitation imposed by the funding cycle or the market. To maximize value, the client needs to be fully engaged in the decision-making process around scope inclusions, deferrals, and exclusions.

Once you understand the agile framework you’re operating within, the real challenge is making sure your clients and other senior stakeholders also understand that an agile approach to project delivery requires very different governance and decision-making processes. Organizational agility starts at the top by setting the right challenges for the agile teams within the right funding model. The next step is to use appropriate assurance functions to make sure agile teams are delivering what’s needed to create value—old-fashioned budgeting processes are unlikely to be appropriate.

How do you go about engaging your senior stakeholders in this type of conversation?

Posted by Lynda Bourne on: August 24, 2017 07:16 PM | Permalink

Comments (28)

Page: 1 2 next>

Please login or join to subscribe to this item
Very informative....Thanks

In such projects, requirements elicitation is very important and what are the accepted criteria for the product sign off should be agreed coupled with assumptions with the key stakeholders.

This can help to keep the focus on the end product needs. Also new changes need to be assessed along the sprints and quantified.

In my experience, i faced similar situation where with passage of time, key stakeholders got less interested on the project due to certain objections or new requirements added by certain stakeholders, which disturbed the business case and the project was stalled.

To avoid this continuous stakeholder engagement, communications and clarity between needs, desires, wants and this is how it was done earlier has to challenged. Finally agreed upon in order to remove the vagueness in validating the deliverables, keeping in mind there is always room for improvement and improvement will cost time and money and certain features can be added larter, if agreed upon.

I agree getting and keeping stakeholder engagement and informed understanding is a major challenge on every project Ganesan Balaji. But in the third type of project outlined above trying to set defined acceptance criteria at the start when you don't know precisely how the 'challenge' will be defined or resolved is damaging. The buy-in needed from executives is to participate in and guide the journey to first define the solution and understand 'success' and then deliver the solution successfully. Seeking certainty where it does not exist simply creates failure.

I agree that trying to define a set acceptance criteria in the 3rd type of project is damaging.

In the environment i was in, various stakeholder were very vehemently opposing and highlighting that such loosely defined criteria does not allow the "stage gate" approval.

Here, i believe to clearly communicate the negotiables and non-negotiables, as such metric will indicate there is intended "looseness" for reason and can be finalised during the next stage.

At the same time, the concern was to tie up as many loose ends as possible. Here again, trying to reach consensus or acceptance did not work as every group was opined that they are correct from their point of view.

That is why communication of minimum value achieved is ensured and whether further improvement is required at the current stage should be left to executives.

Unfortunately, this is not a new problem and there are no easy answers. Prof. Eddie Obeng in his 1994 book 'The Project Leaders Secret Handbook' defined four types of project uncertainty (this is summarised in our White Paper at - but despite more than 20 years of discussion far too many executives want pseudo 'certainty' and then experience 'failure' whereas a pragmatic approach to risk and managing uncertainty would deliver far better outcomes. Basically, you cannot be 'agile' inside a fixed framework, and the frame is defined by the executive.

Very useful information. Thanks for sharing

Thank you, Lynda. It is vital to include and share the vision with stakeholders when using agile, especially so in a mixed environment where typical a more traditional approach is used. It does not need to include fancy jargon, just the expectations that there will be increased inclusion and feedback with less emphasis on defining the complete solution, more so on the vision and goals.

I've been struggling with agile vs waterfall for a while now... this helps build clarity.

Most of the projects and companies are moving towards agile due to the fast pace of the industry and rising competition. Keep the stakeholders engaged with some or the other activity be it a testing of a small deliverable on staging before releasing it or getting a UAT on a piece which is completely developed. Effective Communication is imperative. Include the project users in loop for high satisfaction and balanced task completion ratio vs planned tasks in hand in sprints.

One thing to remember Michael is that many projects are not suitable for iterative or incremental development (typically engineering/construction types) where any change to the plan once 'steel has been cut' becomes very expensive. The challenge for project professionals planning to use an adaptive agile approach for the delivery of their project is first making sure the project is suitable for an agile approach, then agreeing with the senior stakeholders where in the 'Agile spectrum' the project sits. As several commentators have noted, this needs effective communication!

This article brought some clarity to the Agile approach.

Agree that Agile add value to project with the type 3, lack of scope defination

Thank you

For the Maintenance Environments, you suggest "The management variable is the amount of work accomplished each month." Would it not be more appropriate to say The management variable is the nature of work accomplished each month.

After all if you have a set number of resources, the amount of work will be pre-determined and static.

To answer the question in your conclusion, I would say that senior management is usually risk averse to internal culture or philosophy changes. The best way to engage them is to show them what agile can do to all the processes you've listed.

I believe that agile frameworks are needed in each Information technolgy project because in such projects the scope is never defined at the beginning.

Good question St�phane, I would suggest in an 'Agile maintenance environment' there are two 'scoping' considerations, the relative urgency of an issue and the available skills matrix to achieve the mix of work (Kanban boards can be adapted to visualize this). These decisions override any measure of efficiency but at the end of the day, you still need to measure the amount of work accomplished and compare with the amount of work being added to the backlog as new issues arise as a holistic assessment to allow team skills matrix and sizing decisions, as well as the more fundamental question around productive efficiency (eg, availability of spare parts). Maintenance is particularly difficult in this regard because the mix of problems occurring each month will vary significantly and the organisation wants their systems working at 100% 24*7 (but does not want to spend money to achieve this).

I know a few organizations, Marouan, who would disagree witht your premise that scope is never defined at the beginning. We often get RFPs that have hundreds of requirements listed and prioritized.

Page: 1 2 next>

Please Login/Register to leave a comment.


"A day without sunshine is like, you know, night."

- Steve Martin