Businesses often jump into Agile without being fully cognisant of the preparedness of the organisation. How can an organisation build standard practices within the business to help identify that Agile is the right approach?
Without a doubt, when an organisation decides to adopt Agile as a delivery methodology, the intent is solve some of the shortcomings of the traditional waterfall approach. However, as is often the case, not all projects are created equal when it comes to the effectiveness of Agile. Some projects, due to their underlying nature and risk profile, are not well suited to Agile delivery techniques.
The organisations that adopt Agile well – and appropriately – have transformed how they execute projects to the point that they are able to adapt to an Agile methodology without significant risk and disruption to the existing steady state project delivery cadence.
So how can your organisation develop an ‘Agile radar’ by building in good project decision-making habits to ensure when Agile is chosen it is the right decision?
Start with the Basics: What is Agile Again?
Agile’s origins as a project delivery methodology first emerged in the mid 1990s to solve challenges in the delivery of software projects particularly the shortcomings of a waterfall approach. The Agile Manifesto quickly took on a life of its own to encompass a way of doing thing that is heavy in terminology, such as scrum, sprints, and stand-ups, to name a few.
The Agile Manifesto was written to express a shared set of values or principles by developers who saw a new and better way of developing software; these were people with decades of experience who came to the same common-sense conclusion that not all projects were being served well by existing waterfall techniques.
While it may not be every project professional’s point of view, there is a truism supported by the history of Agile that not all projects lend themselves equally to Agile techniques. The challenge for any organisation running projects is the ability to identify the key signals that suggest when the project lends itself to an Agile approach.
Is This the Right Type of Project for Agile?
The first clue that organisations can consider is one that exists in the evolution of the methodology. Driven by software development professionals, there was one specific KPI that needed to be achieved: Speed.
Considering Agile for any project should ask, as a bare minimum requirement: Can the projects we are considering running as Agile be accelerated?
It’s an important question. Some projects by their nature carry higher levels of risk, for example, infrastructure projects. Whilst we are not saying non software development type projects cannot benefit from Agile, but it is less likely and will carry more risk.
Organisations should endeavour to understand the nature of the projects they are delivering and develop some scoring criteria to look beyond speed of delivery to include risk and quality expectations that enables them to identify if the project lends itself to the use of Agile.
Do you Have Access to the Right Business People?
By its very nature, Agile relies heavily upon the business being embedded into the project team to help it make decisions in real-time. The approach means that the team don’t need the heavy documentation and checkpoints of a Waterfall approach to safeguard quality and manage risk, because the business is embedded as part of the project team and able to act on decisions required with the most up-to-date information.
But it’s not just anybody from the business: It needs to be its best SMEs. SMEs at this level really understand the underlying business challenges that the project is attempting to resolve.
A key factor, therefore, is understanding the level of engagement from the business, both in terms of ability and availability, and their desire to remain committed and actively participate in the execution of an Agile project.
Is Your Governance Mature Enough?
Another common misnomer regarding Agile is it lessens the requirement for Governance. Agile does not equal no Governance.
Governance may change within the context of an Agile implementation in terms of the more formal Governance that is associated with, say, Waterfall implementations (i.e. Regular Steercos, formal document sign off, key milestones etc). Agile does not do away with Governance per se; it just changes how the Governance is administered.
For example, a key difference is that it makes Governance more de-centralised, so decision making rests within the project team. The more formal centralised Governance that is typically associated with Waterfall is not required in an Agile implementation. The discipline required to govern Agile projects – particularly the vexing issue of Governance at the portfolio level – is heightened.
The more mature an organisation is with Governance, the more likely it will benefit utilising Agile as a delivery approach.
Can the Project Be ‘’Chunked’’ Down?
Projects are often multi-faceted and our perspective is that the delivery methodology should always be fit-for-purpose, no matter the phase of the project. On the surface, a project overall may not seem to lend itself to Agile delivery, however it’s possible that some of the phases within the project may very well be good prospects for Agile.
Regardless of the delivery methodology selected during the planning phase, a project should always be ‘chunked down’ to de-risk the project and thought given to which delivery methodology will be the best fit for each project phase.
It may be that the project is delivered via multiple delivery methodologies, including Agile. However, achieving this type of flexibility – i.e. the ability to execute multi-delivery methodologies for one project, for example, Agile, Waterfall, Iterative – requires a strong PMO with the ability to support multiple, concurrent methodologies. If the PMO lacks this ability, then it is more prudent to choose a single delivery methodology, rather than adding complexity into the delivery.
Good Project Habits Help to Tune the Organisational Radar
Working out which delivery methodology to use is challenging for organisations, however, our guidance is generally that good project habits make it possible to evaluate the right approach. We believe that having a reliable, well-tuned radar for which projects are best served by specific methodologies is a benchmark for the maturity level across a number of competencies in an organisation’s ability to support the decision making process.
Ultimately, the best methodology is the one that is fit-for-purpose, be it Agile or not. The better your organisation is placed to make this deliberation, the greater the chance it has of getting it right and delivering successful projects.
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.