Comprehensive software reviews to make better IT decisions

Explaining Agile to Management and Your PMO (How to Foster Their Buy-In and Support)

Info-Tech members who are moving to Agile frequently complain about the challenges of explaining Agile to both senior management and their project management office (PMO) in a way that achieves both good understanding and the needed support. Here is one way to explain it to them that avoids unnecessary complexity and focuses on explaining Agile’s intrinsic value to the organization.

Step 1: Begin by explaining the important fundamentals, including:

1. Agile is simply an alternative way of delivering projects that is designed to maximize the value delivered and minimize the risk of building the wrong product/solution.
2. The standard way of delivering projects (known as Waterfall) requires projects to follow a rigidly defined series of steps (define, design, build, test, then deploy) that must be done sequentially. The main problems with this approach are that little business value is actually delivered until near the end of the project and if the project built the wrong thing, you don’t know it until it is too late.
3. Agile addresses these problems by building the product/solution in very small pieces and demonstrating each piece to stakeholders to verify it is of value to them. This means project course corrections can be made frequently to keep it pointed in the right direction.
4. Agile decides the order in which to build these small pieces by prioritizing them according to their value to the organization, effectively making certain that the most important things are done first.
5. Agile also adapts to change much better than Waterfall. By not over committing to what will be built or in what order, Agile accepts change as a normal, and even welcome, aspect of the project lifecycle.
6. But, be forewarned that successfully adopting Agile requires organizational cultural change, which is always hard and risky. Management and the PMO must understand the benefits of this change, and support it, if it is to take root in the organization. They must understand it is a journey that starts small but gains momentum towards full adoption, so they must nurture its growth by eliminating obstacles and being resilient to missteps along the way (don’t go big bang because the organization will need to learn and adjust to early mistakes). This managerial patience will be rewarded by the benefits that successful Agile adoption brings (step 3 below).

Step 2: Do a deeper dive into the differences between Waterfall and Agile (if needed):

1. For those that are unfamiliar with the “Project Triangle from Project Management” explain that it is a “law” of project management that says that for all projects asking to change any one of the cost, time, or scope of the project will always impact at least one of the others.
2. Waterfall and Agile differ significantly in their approach to the Project Triangle (see image above). Waterfall projects generally work on a fixed scope basic. This means that the project cost and time must be variable (because no one really knows exactly how much it is going to take to fully deliver the scope).
3. In effect, Waterfall projects say, “we can tell you exactly what we will deliver, but we can’t tell you how long it will take or how much it will cost.”
4. Agile projects instead tend to work with a fixed time and cost basis. This means that the scope of the project (i.e. how much it delivers) must be variable (because no one really knows exactly how much will get done with fixed time and fixed cost).
5. In effect, Agile projects say, “we can’t tell you exactly what it is we are going to deliver for your investment, but we are pretty confident about how long we will be working on it and how much it will cost.”
6. This is often the most difficult thing for management and your PMO to accept about Agile (i.e. not knowing exactly what they will get at the end). However, accepting this, and even embracing it, comes easily if you understand Agile’s benefits and value proposition (See step 3).

Step 3: Explain Agile’s value proposition and benefits:

1. When properly supported and executed, Agile projects are earned value superstars (earned value calculations focus not on the amount of work being done, but rather on how much value has been delivered by the work done). By using a backlog of work, which is constantly being reviewed and ordered in priority by the business, Agile works in a way that ensures the project team is completing the most important pieces first. This means Agile projects can maximize earned value for your organization. It is worth having patience in the early days of your Agile adoption journey based on this alone. (I will take the earned value of an Agile project at 30% of its timeline over a Waterfall’s at 60% any day!)
2. As if maximizing earned value was not enough, when properly supported and executed, Agile provides two additional benefits which help to minimize project risk. They are:
   1. The Continuous-Tangible-Progress benefit: Rather than having to waiting until very late into a Waterfall project to see the end product and know if it delivers value, Agile projects continuously deliver small pieces of completed, tested, and demonstratable features. This is a far better measure of whether a project is on course than relying on a Waterfall project plan showing percentage completion on paper but little/no working product to demonstrate.
   2. The Ability-To-Stop-Anytime benefit: Because of 1), it is possible to stop an Agile project at any time and still have something of value, which can (relatively easily) be put into production. Compare this to Waterfall where, if you stop the project pre-maturely (particularly during define or design phases, but even into the build phase), you will have little to nothing of value to implement.
3. Finally, Agile’s greatest benefit is its ability to adapt to change. In a world where accelerating change has become the norm, the Agile approach accepts this as both normal and welcome, and so represents an organization’s best chance to effectively adapt to change.

Understanding Agile’s value proposition and benefits in this way can often secure the support you need from senior management and your PMO.

Our Take

First time adoption of Agile in any organization is a difficult and risky undertaking because it requires significant and sustained changes in organizational culture (CollabNet’s 13th State of Agile Report says that “Once again, the survey responses indicate that organization cultural issues remain the leading impediments to adopting and scaling agile”). Achieving buy-in and support from your organization’s Senior Management and PMO is an important step in achieving the needed cultural changes. (For more on the challenges of first time agile adoption and tips to increase changes of success, see Agile Tips the Balance Toward Success for Most Projects (but It Takes Time and Effort to Become Agile).) Use the three-step explanation above to help achieve this support.

Also, don’t forget to provide the training and support needed by your Agile delivery teams. Before undertaking an Agile transformation, consider:

1. Making use of Info-Tech Blueprints (like Implement Agile Practices That Work, Modernize Your SDLC, or the soon to be published Agile Transformation Accelerator) that will help you to plan your Agile transformation.
2. Providing your teams with high-quality training on your chosen Agile methodology.
3. Hiring an Agile Coach to help your organization transition to Agile more effectively (select someone who comes highly recommended by references).

Finally, your chances of successfully adopting Agile can also improve when you incorporate use of automated tools to carry some of the load. For example:

1. Use one of the many available software development management tools that support Agile processes (like Jira, VersionOne, or Helix) to make your delivery team’s job easier and make it possible to easily gather highly valuable metrics (like sprint velocity) without additional effort by the team.
2. Use software test automation tools (like Parasoft, Selenium, or TestComplete) to make regression testing repeatable and less labor intensive.
3. Use team collaboration tools (like MS Teams, Cisco Webex Teams, or Slack) to improve team communication and collaboration particularly for geographically dispersed teams.

Want to Know More?

Agile Tips the Balance Toward Success for Most Projects (but It Takes Time and Effort to Become Agile)

Implement Agile Practices That Work

Modernize Your SDLC

Speak to your Info-Tech engagement rep about our Agile Transformation Accelerator