Is Your Organisation Ready For Agile?

15 August 2017

Home
Blog
Agile
Agile Organization

Agile, or agile ways of working, could be applied to the delivery of any programme. So how do you know when to apply them and when not to? The answer is, it depends.

Agile has proven its value to small self-organising teams (scrum or sprint teams) who are empowered to pull their own work from a backlog and deliver ongoing, incremental business value. Many organisations already have this working effectively within their software delivery functions and want to expand the benefits across a wider portion of their portfolio.

But how do you know if you are ready and able to apply it more widely? Or, if you are ready, where should you apply the techniques to achieve the maximum benefit?

To understand the answer to this, you need to look at two things: the structure and diversity of your portfolio and the business environment in which that portfolio delivers.

Structure and Diversity of the Portfolio

The suitability of your portfolio for agile depends on the kind of programmes and projects you are delivering and the business appetite for risk.

Understanding the projects in the context of infrastructure vs. application, multi-system vs. single system and new vs. refresh is a good starting point. Certain project types lend themselves better to Agile and agile ways of working than others, so understanding what kind of project you have is the fundamental building block to making an informed decision.

You then need to look at the costs of the projects and the value of the benefits that are expected to be delivered. Whichever measure, cost or benefit you use, you need to be confident that it is a realistic value; after all, you will be making an assessment based partly on that data.

In many organisations, benefits identification and benefits management is at a lower level of maturity than the project financial management, so delivery cost is a more stable value to measure. Having both data points is a real advantage, however, as it gives an extra dimension to the analysis.

So now that you have the project type and know either the cost or benefit, the next step is to look at the risk. Risk appetite varies from business to business and will fluctuate over time. But for this assessment you don’t need a deep risk analysis, but instead an overview that will position the risk status of the project within the business and relative to other projects. You can assess risk by asking yourself four questions:

1. If this project fails, what happens to my business reputation, or my Reputational Risk?
2. If I stop this project, how much money am I writing off in my Financial Risk?
3. If this project does not deliver, what impact does it have on my operational capability, essentially my Business Operational Risk?
4. If this project is late, what commercial opportunities am I missing that equate to my Commercial Risk?

These questions give you a great data source to conduct analysis and derive conclusions, but there is another piece of the puzzle that needs to be understood.

The Business Environment

Agile is more than a set of tools and processes. There are many agile practices and a set of agile principles that you can apply to what you do and how you do it. It’s a set of values that determine how you operate and above all, it’s a mind-set. Understanding the business environment can be done by looking at four areas:

Structural

How does the business allocate funding? How does it conduct business planning? What rules are there around processes and controls?

Cultural

Does the governance structure enable Agile? Do the delivery teams have a solid reputation? How does the business feel about uncertainty?

Product

How important is time to market? Does the business encourage innovation? What level of internal dependencies do we have

External

What is the pace of change in the market? Is the business bound by regulation? What third parties are the business accountable to?

A business environment can either enable or inhibit agile ways of working. Understanding the current environment allows for a focus on the areas that can be either changed or further exploited to enable greater agile working.

You can identify which areas of your portfolio could benefit from Agile techniques by understanding its content, value and risk profile, coupled with a review of your business environment and how it could support agile working.

If a project can deliver incremental benefits, with limited dependency and within the risk tolerance of the business, Agile is the way forward. However, experience also shows that high value, high risk projects with no incremental benefits are better suited to, and can be delivered more successfully, using a waterfall delivery method. This doesn’t mean they wouldn’t benefit from some agility, because there is always an opportunity for process improvement.

So, whether you should use Agile or not depends on the application, it’s about using the right tools for the job. However, to select the right tools you need to first understand the job and your business capability to use the tool.