Getting to grips with the two key approaches to project management will help us to become smarter project managers.
Back in 2001, 17 top software practitioners spent a long weekend at a ski resort in Utah's Wasatch Mountains to discuss what constituted best practice when it comes to software development. They concluded that the word 'agile' best described the most successful approaches, and encapsulated their thinking into four key values they called The Agile Manifesto, backed up by 12 core principles.
The Agile Manifesto was a reflection and summary of project management processes and techniques developed specifically to meet the fast-moving world of turn-of-the-century software development. In some ways, it can be seen as another iteration of the famous Toyota Production System of the 1950s, the first project management system based on lean- and workflow- based approaches to project management that have been adopted and adapted ever since.
But the manifesto has become an influential blueprint and mantra for any number of tech companies and start-ups, spawning a community and fanbase that has had a major impact on the world of project management – and beyond. While the story of The Agile Manifesto has largely played out in the software industry, commentators and researchers have also asked whether this most contemporary vision of project management can be adapted and used in business more widely.
Just as Agile project management has pitched itself against more traditional project management techniques, leadership based on Agile principles and values has been seen as a similar foil for traditional top-down, command-and-control, business-knows-best approaches to running organisations.
That’s quite a claim. But, leaving aside the hype, what does this all mean for how we manage projects? Should it be Agile all the way now? Let’s rewind a bit to find out.
In essence, project management is a structured process for delivering those discrete pieces of work designed to achieve a particular goal: projects. As projects have become an increasingly important part of how we operate and drive business performance, understanding the defined sets of processes that underpin project management has become an important skill for leaders to master. Project management is no longer the sole preserve of specialist project managers.
However, if we Google the term 'project management', we’re likely to come across a whole series of approaches, systems and frameworks that can, at first, confuse rather than illuminate: Scrum, Prince2, Waterfall, Kanban, Design Thinking and Agile. What do they all mean?
There are a variety of interpretations and terms used, but one way to sort the wheat from the chaff is to differentiate between approaches to project management and the various systems or frameworks that lie beneath them.
It’s generally acknowledged that there are two main approaches to project management:
A linear, sequential approach, where each step in the project is completed before the next starts and the end-point is well defined, known as Waterfall.
More Agile approaches, as outlined in The Agile Manifesto, based on iteration, with work completed in planned, cyclical increments and each increment bringing greater clarity as to what the final outcome will be.
Whatever approach we use, we will still need to follow a defined set of processes (mapping, planning, implementation and monitoring, and closing and evaluation). But the approach we use will influence how and why we deploy each process.
Once we’ve thought about the general approach we might take, then there is a whole range of proprietary systems and frameworks that might support the project management process. For example, Prince2 is a classic Waterfall framework that emphasises clear steps and well-defined responsibilities, often used in large-scale projects with more predictable steps and goals.
The waterfall approach also underpins tools like Critical Path Analysis. Scrum uses agile principles based on series of short-term 'sprints', customer feedback and regular iteration. Kanban boards offer a visual summary of workflow and progress, designed to make it easier to visualise work processes, spot problems and take corrective action. Agile frameworks such as Design Thinking are even considered as a mindset, a flexible, iterative approach to problem-solving more generally.
Increasingly, too, the two approaches might be used alongside one another at different stages of the project. Unless we’re majoring as project managers, we’re unlikely to need to a become Prince2 certified user or a 'scrum master' (yes, this is a thing). But knowing more about how the two key approaches work, and adopting and adapting some of their key elements, can help us to manage our own projects, no –matter how small or large.
A Waterfall approach to project management follows a sequential, linear process which consists of discrete phases – or critical path - moving towards a clearly defined goal. In the face of the Agile movement, it has often (unfairly) been seen as a more traditional – and rigid – way to manage projects.
However, it has proved to be remarkably resilient, and with good reason; it might not work in the context of rapid iteration software development, but it’s a proven methodology in sectors such as manufacturing or construction and beyond.
In a Waterfall-based process, no phase begins until the previous phase is complete, and phases do not overlap. Proper planning and documentation are a must; project requirements and roles must be clear upfront, and everyone involved in a project must be well aware of those requirements.
Because of the investment of time at the planning stage, it’s assumed that, once the project’s design and requirements are clear and communicated, the actual project will cascade quickly and smoothly, like a Waterfall, when it comes to implementation (hence the name). Think Abraham Lincoln’s famous advice that, if he were given six hours to cut down a tree, he would spend the first four sharpening the axe.
In contrast, Agile project management favours a fast and flexible approach, bringing cross-functional teams together in continuous cycles of quick, responsive actions that help products or processes evolve. Implementation is integrated with planning so that working prototypes (sometimes known as minimum viable products or MVPs) become a means of assessing project progress and of testing – and further iteration.
Flexibility, change and adaptation are not just embraced, but actively encouraged. Crucially, it involves a focus on stakeholders like customers or users throughout the project and not just at key milestones. To get it right, it also needs high levels of commitment and collaboration from motivated, self-regulating and cross-functional teams.
In short, it embraces those four key values of the Agile Manifesto:
Individuals and interactions over processes and tools
Working software (or any prototype product or service) over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile proponents generally see the working environment as being far more complex and unpredictable than planning to cut down a tree. They are more likely to take heed of Mike Tyson’s sage warning that “everyone has a plan until they get punched in the mouth”.
Some common Waterfall and Agile frameworks and tools
A process-based approach that focuses on organisation and control over the entire project, from start to finish. Projects are thoroughly planned and documented in advance and each stage of the process is clearly structured. It has seven defined phases: start up; initiation; direction; boundary management; control; delivery; closing. Project roles are strictly defined.
Good for…
high stakes and zero tolerance environments; close monitoring at every stage.
Less good for…
avoiding bottlenecks; less structured or faster-moving cultures.
Developed by Motorola’s Bill Smith in the 1980s, Six Sigma is based on a cycle of continuous improvement and eliminating defects in a product, process or service. It has five defined phases - define, measure, explore, develop and control – and offers a structure to plan and define goals, and test for quality at each stage.
Each phase can be customised, depending on project needs, with the measure and control phases providing opportunities to review, learn and improve.
Good for…
complex, data-driven processes; processes that are continuous and non-finite; learning and development.
Less good for…
simpler, more finite projects; where continuous learning would be superfluous; less structured or smaller organisations.
A technique that focuses on defining and illustrating in diagram form the interdependent and crucial sequence of events. All tasks are clearly defined and a minimum and maximum time allocated to each, determining the shortest possible time for those critical path elements.
Good for…
complex, time-critical projects; visibility on time constraints within an overall schedule; identifying potential slack in a schedule.
Less good for…
flexible projects with less clear inputs and outputs; teams with less well-developed project management capabilities.
Work is divided up into short timeboxed iterations called sprints which usually last between one and three weeks. At the end of the sprint, the cross-functional sprint team meets to review the completed work done, how the sprint went, and to plan the next sprint.
Daily planning and tracking of progress is visual, using tools such as a Scrum board and sprint burndown chart. Scrum has three roles: Scrum master (team ‘coach’), product owner (responsible for delivery) and team member (typical five to seven per team).
Good for…
technically complex projects that require multiple deliverables at speed, such as software development.
Less good for…
less complex projects that do not need the Scrum infrastructure, or where teams are larger or less experienced.
Japanese for ‘signboard’, Kanban focuses on visualising the constant flow of tasks and work in progress. ‘To do’ items move along a series of vertical columns, which show the current status of that task (for example, plan-develop-test-deploy-done). New work cannot be added until existing work is moved to the next step in the process. There are no prescribed roles for the team.
Good for…
projects where the overall time taken is less crucial; regular, steady output such as a production line.
Less good for…
projects with tight deadlines or tasks subject to fluctuation or variation.
A phase-based approach to problem-solving where the phases are not necessarily linear and can be used in parallel or iteratively. The five-stage Design Thinking model proposed by the Hasso-Plattner Institute of Design at Stanford suggests the following five phases: empathising, defining. ideating, prototyping and adopting/ testing.
Good for…
consumer product innovation where customer engagement is key; simple problems with no single right answer.
Less good for…
more complex problems; where a defined outcome is required.
It’s easy to see why more traditional Waterfall-style approaches are under pressure. Strict process and defined roles seem increasingly at odds with the fleet-of-foot world of tech giants such as Amazon or Google. Examples of companies that have failed to adapt and change — from Kodak to the big hotel and car companies that just didn’t seem to see Airbnb and electric cars coming — are legion.
In response, the battle lines have been drawn. Consider, for example, the rise of holacracy, a radical, ‘no bosses’ organisational structure which takes the agile principle of self-managing teams to the extreme. Developed by software engineer Brian Robertson, its proponents remain bullish. But another early adopter, the online publishing platform, Medium, dropped it after a tricky three-year experiment.
When founder Evan Williams announced that Medium was abandoning holacracy, he cited, as the major cause, an obsession with process that was getting in the way of doing the work. It’s a criticism that’s also been levelled at leading agile project management methodology, Scrum; the sense that it’s become as inflexible and hierarchical as any traditional waterfall approach.
As far back as 2015, one of the authors of the Agile Manifesto, Andy Hunt, bemoaned the fact that “the word ‘Agile’ has become ‘sloganized’ leading, at best, to meaningless and half-hearted attempts at agile; at worst, to Agile zealots who continue to “redouble their effort after they’ve forgotten their aim”. Adopting abstract agile concepts can be difficult; in the race to make sense of them, “agile methods themselves have not been agile”. The irony was not lost on Hunt.
Stephen Denning, author of The Age of Agile, firmly believes that agile concepts have become an essential route map for management more generally. But for Denning, agile management is about much more than harnessing data and technology or learning lessons from software development.
It implies a different approach to leadership and management, focused on generating “more value from less work”. He argues that, on their own, traditional hierarchical bureaucracies cannot respond to the complex problems that organisations are increasingly facing, challenges that require collaboration across internal silos and routine interaction with customers.
Instead, he has identified three common characteristics closely associated with organisations that have successfully embraced agile management, all of which would be familiar to the founders of the Agile Manifesto:
1. The Law of the Small Team.
Small teams working on small tasks in short, iterative work cycles delivering value to customers.
2. The Law of the Customer.
A continuous focus on adding value for customers.
3. The Law of the Network.
Co-ordinated work within an interactive network.
Crucially, that doesn’t mean that agile organisations are completely flat or non-hierarchical; top management still sets direction. That management is based on entirely different assumptions, a different mindset — in Denning’s words: “a hierarchy of competence, not a hierarchy of authority” — but it still exists. His agile management paradigm is a journey, not a destination. Companies never really ‘become’ agile: rather, an agile mindset involves “never-ending innovation” that requires “continuous commitment and leadership from management.”
It’s a compelling thesis. Mindset change is one thing; wholesale abandonment of management approaches that have served organisations well for decades is quite another. Waterfall-style project management still has a place where iteration is simply not possible or desirable, regular customer engagement is not feasible or a critical path may still be critical. Context, of course, is everything.
Writing in Harvard Business Review, Darrell K Rigby, Jeff Sutherland and Hirotaka Takeuchi offer a rousing call-to-arms to reluctant or ill-informed executives to better understand the power of Agile and how it can transform business beyond the world of project management. They cite useful case examples for how agile can be embraced to best effect.
But even these evangelists are clear that agile is not a panacea, and should only be deployed under the right conditions, when “the problem to be solved is complex; solutions are initially unknown, and product requirements will most likely change; the work can be modularised; close collaboration with end users (and rapid feedback from them) is feasible; and creative teams will typically outperform command-and-control groups”.
They suggest that fertile ground for agile approaches include product development, marketing projects, strategic-planning activities, supply-chain challenges and resource-allocation decisions. Less productive might be routine operations such as maintenance, purchasing and accounting.
Hybrid approaches to project management, based on waterfall and agile techniques working alongside one another, are also another way to extend the reach of agile. Management consultants, McKinsey & Company, believe that truly agile organisations need to reconcile the seeming paradox of both “stability and speed”.
Mastering this paradox means creating a stable core, while championing looser, more dynamic elements that can adapt more quickly to challenges and opportunities. A 2018 report from the McKinsey Agile Tribe charts the move away from what it calls organisations as machines (hierarchical and specialised) to organisations as organisms that combine “stable backbone elements that evolve slowly and support dynamic capabilities that can adapt quickly to new challenges and opportunities”.
Back to those projects we have to manage. Whether we see agile as a project management approach or a leadership mindset, it seems clear that few, if any, organisations – or projects – are entirely Waterfall or Agile.
Instead, we might view Waterfall and Agile are umbrella terms that encompass a variety of practices and approaches. While agile is often associated with large-scale software development, as we’ve seen, its roots lie in lean manufacturing and organisational learning. Scrum techniques such as stand-up meetings and weekly iterations or visual management, like those Kanban boards, can apply to any project. And step-based waterfall tools such as Gantt charts can be used to track the progress of the likes of Scrum sprints.
Even the Agile Manifesto originators talk about balance. We need to work out when to be more agile and when to focus on that more stable core. Which approach we use – and when – will depend on a range of different factors from the type of project itself, to the people working on it and our organisation context and culture.
Rather than pitching waterfall and agile approaches against one another, we might instead see them as complementary tools and techniques in a toolbox of options. If, according to American historian Henry B Adams, “Chaos was the law of nature; Order was the dream of man”, that doesn’t mean we can’t also subscribe to a bit of Shakespearian “Nimble thought” that “can jump both sea and land”.
Explain the two main approaches to project management.
Identify two of the four Agile Manifesto values.
Outline the five phases of the Design Thinking framework.
Do some research into some common agile project management frameworks and tools, such as Scrum or Kanban boards. Consider how you might incorporate two new Agile techniques into your project management processes.