Agile has become part of the project management vernacular, however, the way it is adopted is far from universal. The question is this: How should it best be introduced to project delivery?
Without a doubt, the near-universal adoption of Agile as a project delivery methodology over the past few years has proven that far from being a fad, it is here to stay. Considering how many organisations are now walking an Agile path, there are some stark differences in how it is being introduced, governed, managed, and evolved.
There are extremes, such as the skunkworks projects beavering away off the radar (with more modest budgets and, sometimes, objectives) and at the opposing end, we have the “We are going Agile” edicts where the organisation as a whole is mobilised and directed to deliver in an Agile way across the board.
Both approaches can and have been successful, but neither is an easy pathway.
Approach 1 – Let it Bubble up to The Surface
The bubble up approach to Agile adoption typically sees a small cohort of highly motivated individuals with a strong desire come together to collaborate and deliver a pressing business outcome. These are normally projects with a compressed timeframe and a compelling need from the business.
The cohort has assessed that existing practices won’t cut it and that they need to step outside the standard delivery playbook and try a new approach. If we dig deeper, it may be that the people who lead the Agile delivery are already skilled in the approach and that their team members are open-minded and willing to try new things.
This makes for a highly motivated team that will bend over backward to demonstrate the value of an Agile approach to successful delivery.
In innovation sessions, there is a guiding principle that people are naturally drawn to certain problems or projects and that self-selection is the best way to achieve the best team. A second insight is that as these projects are often skunkworks i.e. small teams that work on projects in unconventional ways with minimal management constraints. They often avoid traditional governance and reporting obligations and that enables them to be more dynamic and able to change direction at their choosing.
This often leads to initial success and then the teams disperse back into the organisation, motivated by their new-found success to employ components of the Agile way or working back into their traditional delivery approach. What starts to emerge is the daily stand-up, feature backlogs, user storyboards, and the like starting to make an appearance in waterfall projects.
Slowly, but surely enough pressure is brought to bear to formalise Agile as “the way of working” for the organisation. Hybrids start to emerge where Agile ways informally permeate into traditional project delivery methodologies until such a point as Agile gets the formal nod and is adopted as the go-to approach for project delivery. As Agile becomes ‘legal’ and no one has to move under the cover of darkness, the expectation of fantastic results builds on the momentum of earlier bubbles.
However, be warned the reality can often be the opposite as once you move away from a small dedicated, skilled team to the wider user group who may lack the expertise you introduce risk as you always do with any change to ways of working. Projects can start to fail, cost blows out, uncertainty starts to build, and organisational confidence in Agile once high can begin to dwindle.
Approach 2 – Going Big Bang!
Another Agile adoption approach is more abrupt: The “big bang” of a Lets-Go-Agile approach is the polar opposite of the bubble up effect. This can happen when there is too much Agile Kool-Aid in the picture and it starts to overflow, the posters are on the wall, and a game of proverbial Agile ping-pong starts being played. Everyone is ready for results.
While a stimulating environment is often valuable to be a part of, the results don’t always match the expectations as this can be a pretty radical change for an organisation. Pockets of success and pockets of failure emerge, but when the failures appear, questions are asked, fingers are pointed, and the “I told you sos” take their place at the lectern.
Is There a “Right” Agile Pathway?
If the decision has been made that Agile is the right way to go, why are things going wrong? To start with, there are some reality checks:
- Agile is one way of delivering projects, not necessarily the only way
- Agile means different things to different people
- Agile is really about cadence (the speed at which we produce outcomes)
- Agile is all about people
Taking these reality checks into account, and asserting that to be successful, Agile must be a fit-for-purpose approach, project teams must understand what it is and what it isn’t, that projects must deliver continuously in small chunks, and that people must be along for the ride.
The bubble-up approach is more likely to have these conditions in a smaller, insular team. However, as Agile begins to permeate across the organisation, it is easy to see that they may not.
In a top-down or big bang approach, it’s likely that in many instances, one or more of these conditions will not be quite right, which will lead to a more challenging and different adoption of Agile.
It’s Not About the Methodology
Irrespective of the delivery approach, the focus of Agile needs to be on the outcome. The starting point of success is “this project will be successful when…” and then all decisions are played against this definition.
It is possible that some components of the project can be delivered in an Agile way, some iterative, some waterfall, and all will be combined to deliver outcomes.
The real trick is to not be single-minded or overly rigid in your thinking that one way is the only way, be it agile or any other methodology.
We believe that quality thought leadership is worth sharing and encourage you to share with your colleagues. If you’re interested in republishing our content, here’s what’s okay and what’s not okay.
To speak to our team about how we can help your business deliver better projects, please contact us.