A little rant, if you’ll forgive the indulgence. It includes a confession, to make up for the ranting.
You might have heard talk about new project management methodologies that try to combine bits of agile and bits of non-agile into one unified thing. I don’t think that’s a good idea, and I want to explain why.
We’ve been doing a lot of talking about agile recently. We’ve always said we’re pragmatic, not dogmatic, about it. Each team uses agile in the way that suits them best.
Confession time
Of course there are different approaches to project management. Waterfall is one. So now’s the time for the confession: believe it or not, I am a qualified PRINCE2 Practitioner. I got my certificate back in 2007. I suspect it’s lapsed by now. The point is: it has its place. We’ve all used roads and ports built this way, all of them useful pieces of infrastructure.
Digital public services are infrastructure too, but of a different kind. When they’re live, they’re just that - live. We’re not building software projects that can just be signed off: we’re delivering ongoing, maintained services. Services whose users will have needs that will change over time. We shall keep updating and iterating, because we don’t need services to match a prospectus that a project manager, however well-meaning, wrote years ago. User needs should be written into the DNA of a service, not spliced in as an afterthought.
Agile as a way of life
Combining agile and non-agile into a jerry-rigged mishmash misses the point of working in an agile way. Teaching people about agile and agile terms doesn’t need a newfangled management-speak hybrid. Traveling around the country to visit the 25 exemplar services, I saw people who had traditional project manager backgrounds but who had seen the benefits of agile. Agile isn’t just a set of rules, it’s a mindset. An approach to solving problems and meeting user needs. Let’s not lose sight of that.
Being agile doesn’t mean you give up on governance or deadlines. The idea that agile somehow “needs” a waterfall-type methodology to give it control and governance is nonsense. When you work in an agile way, governance is built into every step of what you do. You build and iterate based on ongoing user research. You build what users need, not what you guessed might be a good idea before you even started building. That means spending money throughout the lifecycle of a service. Not throwing a lot of money at a project upfront, without knowing if it’s going to be useful. Or not.
As for control? I guess you have to ask yourself what you mean by control. Does control mean that you build something, on time, on budget, focussed entirely on what you’ve decided at the beginning, before you even started building? Regardless of whatever that might mean for users - today, or in ten years time? We know that people simply aren’t very good at working out what might be needed or what might go wrong before they start a project. You might be lucky, and indeed build the right thing. But that doesn’t sound much like control to me. Listen to what Alan Eccles, the Public Guardian, says about control in this short film we made about his organisation’s adoption of agile: “I have more control now,” he says.
Just go with agile in the first place
In my view, formalising a mishmash approach is going to end up giving you the worst of both worlds. You won’t get the thing you planned on the date you planned it, and you won’t get something that meets user needs either. You’ll end up with something that fails on both counts.
Agile accepts that the scope of the project will change over time. And we know that will happen in government. We know the thing we start working on will not be the same as the thing we get at the end. Requirements will change, budgets will change, the scope will change. Agile lets us deal with all of that, efficiently and gracefully.
So: if you’re working on digital public services, just go with agile in the first place. You’ll save yourself - and most importantly your users - a lot of grief and heartache later on.
Follow Mike on Twitter, and don't forget to sign up for email alerts.
23 comments
Comment by Denis Shaughnessy posted on
The 'horses for courses' philosophy is so obviously right that I can't understand why anyone would argue with it. Agile has become a trendy fad, which is a shame because the trendy fadiness will end up harming the reputation of agile when it fails to deliver its reputed benefits after being applied inappropriately.
It is a failing of judgement when methods such as PRINCE or agile are mandated without a prior analysis of their suitability for the task at hand. I would like to see more thought and guidance about how to choose and tailor the most effective management methods for a given type of project.
Comment by Simon Redding posted on
Hi Mike,
Normally, I'd agree with everything you say, but there's perhaps a misconception here, as Bernie points out above. PRINCE2 is not a waterfall methodology - it's just a set of control mechanisms, which can be applied to many ways of working. Problem was, the majority of PRINCE2 Practitioners, myself included, were only doing waterfall projects until a few years ago, when we all decided to work in a much more sensible way, listening to & involving our service users & flexibly iterating based on their input. However, that doesn't mean that the control mechanisms & quality assessment approaches that were used for those waterfall projects can't be used in agile projects where there is a higher impact of failure. After all, PRINCE2 doesn't even mention "waterfall".
So, reserve your ire rightly for the inflexibility & inattentiveness to the users that's redolent of waterfall, but don't tar PRINCE2 with the same brush. Something like PRINCE2 agile is 100% agile, not a half way house: it's just agile with a bit more communication, control, governance & reporting around the sides of the team.
Cheers
Simon
P.S. Good luck with the new job!
Comment by David Murphy posted on
Seems to be the old story that Waterfall works purely sequentially, whereas in reality you do build in change management to waterfall projects and its possible to have controlled iterations and prototypes.
Agile does not work if all involved are fully involved and engaged - and I include the business people in this. Business management love agile until their own commitment is revealed. Try to get business staff to review a delivery every two weeks when they are all under the cosh to deliver their day jobs, for example.
Business people managing budgets and having to be profitable need certainty - they need to know what they will get and for how much. Even Agile gurus came to realise that.
You can't be agile in IT but not in the business, particularly as any IT investment has to make a calculable return on its investment - government initiatives don't.
I favour agile but its not a panacea.
Comment by Seo Keo posted on
PRINCE2 is flexible by default. To put Agile (with its roots in software development) into the PM world, we need change not a mindset but culture of organisations. The whole approach to handling a change in the enterprise must be reworked. Employees must be empowered to work in an Agile fashion rather than be "engaged" in Agile projects. It should be a new business normal.
There is nothing wrong with Waterfall. Making shorter phases and adding extra loops to refine the outputs makes it quite effective and modern.
Agile not a bad song, but unfortunately, it is still not a hit.
PRINCE2 Practitioner.
Comment by Phil White posted on
This article was a really good read, having little experience in government projects I had no idea there was such fervour for agile. Also, it’s great to see the misconceptions around agile lacking governance being challenged, on this point I agree with Nathan that educating sponsors and stakeholders is vital; it needs to be clearly and convincingly demonstrated that locked in requirements with fixed times and costs are nothing more than a blissfully ignorant security blanket. Needs and priorities evolve over time and unknown unknowns will always emerge. We have too often been involved in what we believed to be large agile projects only to find out part way through we were actually sat within an overarching Waterfall project, with a “You are here” pointer on a Gantt chart.
Comment by Richard posted on
Really great to see so much discussion on this. I like the comments that relate the approach taken to the environment being worked in, the problem domain to be resolved by the change, and most especially the people involved - their experience, knowledge, skills, and personalities. Mike Bracken is right that agile is a mindset, and that mindset looks at problems from a people-centred point of view. The best example of this is the Toyota Way itself, and the Kanban approach based on four principles: “Start with existing processes”, “Agree to pursue incremental, evolutionary change”, “Respect the current process, roles, responsibilities and titles”, and “Leadership at all levels”.
To me, the principles of Kanban also apply to transformation of organisations to an agile approach, a journey much of UK government is on. UK government has been told for many years to use PRINCE2 (and before that PRINCE, created in the 1980's). It has had mixed results, just as any approach has when applied in a broad-brush way. But people in government are now very used to using it, and some (not all) are challenged by moving away to "agile chaos". They don't understand how "mindsets" and "principles" can replace clear control and governance. They need educating and transforming, of course - the agile mindset is a good improvement in approach, so it needs to be in all our toolboxes to use when it is appropriate. The way to do it is to use an agile, transformative, Kanban approach - apply the principles to form the transformation.
This means PRINCE2 Agile can be a useful tool to aid people along the journey, using language and controls they understand as an incremental change towards the improved mindset sought. Those not yet convinced by the agile way can gain understanding through doing, while feeling a degree of control that can be relaxed over time. During the transformation, the team might be described by some as "half agile" with an aim of becoming more than half, and then perhaps whole. Others would say they are agile from the start, as they are adopting the agile manifesto principles even if they are adding a layer of control some would see as restricting and not agile, for a time. But don't slam them for wanting to take time to adjust, and being "half agile".
And my guilty secret? I was part of CT3, the Methods Branch at the CCTA in the 1980s who took a method called PROMPT and turned it into PRINCE. You can blame me and my colleagues!
Comment by Fran posted on
To respond to the heading, rather than comparing Agile to hybrid agile to waterfall. May be not half agile but part? Even a waterfall environment benefits from decent grooming strategies, from user story estimating and a backlog, from an idea that we do not need a fully signed off spec to make a start; from the idea that the users should be committing time effort and input all the way through; from definition of done, from early user testing.
There are opportunities to deliver an Agile culture to a fully delivered systems, before taking the concept over to a new build too.
Comment by Kane Simms posted on
It's purely a horses for courses situation in my opinion. Obvioulsy a purely Agile approach would fit most digital development projects, but most digital development projects in most public organisations are sponsored by typically traditional people with the traditional project management mindset of waterfall/PRINCE2.
It's really difficult to persuade someone who's been in government longer than you've had to throw out everything they've been doing over the last 3 decades and trust us with this - in their eyes - new shiny approach. It's easy to do this when you create a brand new department with the sole purpose of delivering digital innovation in government, like GDS, but a lot harder to even persuade others to give it a try in an established department steeped in status quo upholding tradition.
Perhaps that's what's created the proverbial gap in the market for a hybrid: to turn the traditional-style project sponsor's head towards agile?
In my opinion, it's better to rip off the plaster quickly and create wholesale change that forces people to work in new ways and learn the skills required along the way, but in large, beuracratic and traditional organisations, they're not likely to have the same drive and approach to taking risks and chances and are far more likely to err on the side of caution and opt for a hybrid.
Comment by Ray Ahern posted on
The criticism by Greg Smith that PRINCE2 can't be much use for Government projects because it's " 'In Controlled Environments' (which) hardly describes most public sector" projects shows a staggering lack of understanding of PRINCE2 for someone making such strong statements.
PRINCE2 provides some approaches that help you to control the environment. Of course it doesn't assume you start with a controlled environment but then you'd need to read to about Page 4 or 5 of the book to realise that.
Comment by Barry Anderson posted on
Good call Steve !!
Perhaps GDS could ask AXELOS for a borrow of their P3M3 Capability Maturity Assessment (about the only thing not mentioned by now) to assess maturity - after all UK Cabinet Office owns 49% of AXELOS so presumably they'd get mates rates. It's a great tool for organizations that have already picked the low hanging fruit and need to build real capability.
Jim, nobody is ignoring the people aspect - remember people, processes etc - these methods are there to support people to renew cultures and undertake transformation. These methods just help us to agree what we want to do and support us getting there.
Comment by jim frewin posted on
One simple blog that highlights yet again the myopic industry we work in. The dogmatic focus and protectionism of our favourite or preferred methodologies. We forget that Agile, Prince2, OOPs, PPM, Scrum, Kanban, Lean or whatever other label we want give to methodologies, none have ever actually delivered anything and they never have and never will transform any organisation. People deliver and transformation can only be achieved through people. Without the right mindset and culture no methodology will ever truly deliver transformation but with the right mindset and culture the people just might!
Comment by Steve Boronski posted on
Mike, I love your enthusiasm for agile, however you need to be careful not to become an evangelist.
I'm reminded of a government agency that handles millions of transactions per month who figured Six Sigma would help, and it might have, but when running services the tools are different from manufacturers. They ended up with a shadow board on every desk where pens a pencils needed placing. And, active and inactive bananas. Stupid dogma.
Running a service has never ever needed project management. Setting up a new service or significantly changing it always will.
Another case where agile would not work is when you do not have stable teams to run sprints, scrums, time boxes or any other thing the agile community decides to call them.
I worked with a large private sector body delivering services to the public, they won some contracts and needed to massively and quickly grow. They tried to PRINCE2 their yearly cycle because in this environment you need a degree of command and control. PRINCE2 didn't work and neither would agile, MSP would probably have helped though.
I ran an IT programme of 180 strategically important projects, the whole department consisted of half that number if staff in total. Agile, PRINCE2, MSP and ITIL, not even Lean will help, P3O and MoP did.
What I'm trying to say is that there are the right horses for the right courses, saying agile is the only way is flawed in the same way all the above were. Just like agile teams, each organisation learned, and the community developed guidance to help.
Kanban boards? I attended a BCS meeting where the presenter showed how he was trying to improve his software developers morsel by using this tool. It didn't work because they didn't understand why people were demoralised. It was because nobody ever used their software even though they were involved. What did help? A PRINCE2 business case.
PRINCE2 Agile helps blend the BEST of both worlds and most mature agile organisations have or are doing something similar. Perhaps GDS is not yet mature enough.
Comment by Barry Anderson posted on
Sadly Mike Bracken seems to have overlooked the difference between transformational change and "agile" activities conducted within a continuous improvement BAU environment.
Why do I draw that conclusion ? To quote Mike "You build what users need, not what you guessed might be a good idea before you even started building. That means spending money throughout the lifecycle of a service. Not throwing a lot of money at a project upfront, without knowing if it’s going to be useful. Or not." and "We know that people simply aren’t very good at working out what might be needed or what might go wrong before they start a project. You might be lucky, and indeed build the right thing".
Hmmm......Does that sound like a stakeholder engaged, product description driven approach to a business case that got through any form of governance.
Me thinks not Mike !!
Lest easily influenced souls are being lead astray, MSP and PRINCE2 exist because it is the accountability, rigour and discipline of project management processes that underpin the creativity and innovation we all need to improve our government services. AXELOS is being brave enough to provide clarity as to how within that working environment we can enhance performance by improving the "agility" of delivery. The last thing we need is another PMBoK versus processes turf war Mike. Just get on with passing the current P2 Practitioner so you too can benefit from this "transformational change in business processes".
Comment by John Howarth posted on
I disagree Mike. I think PRINCE2 Agile is exactly what is needed. Anyone wishing to make their own mind up can read about PRINCE2 Agile here (it includes a link where you can download the first three chapters of the new guidance for free) https://www.axelos.com/best-practice-solutions/prince2/prince2-agile
Comment by Ada Brown posted on
Can't agree more with the opinion of the post. Especially the one that agile isn’t just a set of rules, it’s a mindset, which can also be applied into other constructions like in lifescience projects. Nice share!
Comment by Bernie Leadbeater posted on
No problem with anything said here, except the apparent assumption that PRINCE2 is for waterfall projects. As the new PRINCE2 Agile guidance explains, PRINCE2 is already Agile-ready, using scope and quality tolerances to facilitate such things as time-boxes (SCRUM) and flow-based working (Kanban). In a project with one work stream (product backlog), a light use of PRINCE2 might be appropriate, to ensure that their is a business case for what being done, and to keep the sponsors happy, but may not be necessary at all. With more than one work stream (more than one product, therefore more than one product backlog), there is a need for something to pull it all together, and PRINCE2 is certainly appropriate here. Obviously this is a very simplified view. I don't have time to reproduce the whole of the guidance here 🙂
Comment by Greg Smith posted on
But "Agile" isn't just a mindset - it's also a bunch of methodologies (Scrum and so on) which do have rules; it's a term that does have wider meanings and connotations so you can apply it to things at random and make them sound funky; and it's a word which is becoming a magic wand for all that's wrong in public sector project management and beyond. A bit like, funnily enough, PRINCE2 was in the mid-noughties. The problem with both is the odd but resilient idea that because something new and shiny is great in some circumstances, it is great in all circumstances. In fairness, the clue that PRINCE2 wasn't the magic bullet for everything was there in the name: "In Controlled Environments" hardly describes most public sector projects.
That didn't stop us from training thousands of people in it (including me), most of whom (including me) went back to their projects and built a configuration library because they couldn't really see how you would apply the rest of it to an in-flight policy-change project where the scope changed weekly, none of the workstreams reported to the SRO never mind the PM, and there was no budget.
Agile is clearly better than what went before for delivering software which can be broken up into manageable chunks like Digital services. Exporting some aspects of Agile can certainly help improve the way we do some other things - when I learned Agile it turned out I'd been using quite a lot of the principles in the ragbag approach to project and programme management I'd developed through trial and error over the last decade. But if all I'd done was import Agile, I'd still be standing there in about 2007 wondering how you define the MVP for a restructuring project and why the lawyers wouldn't let me iterate my way to compliance with the new legislation we'd just delivered.
There's certainly some opportunism going on - rebranding courses and methodologies as x plus new shiny thing isn't a novel idea, but that doesn't justify a blunt statement that it can't work. The approach of cobbling together a toolkit from various sources and deploying it in a responsive way depending on the nature and scale of the change has worked for lots of people, including me. I strongly doubt that there will ever be a single methodology that can fix all of the challenges in managing change of any kind - Agile certainly isn't it.
That said, as soon as I can think of a better name than "PRINCE2/ MSP/ APMP/ MoR/ templates nicked from all over the place/ years of painful experience plus Agile", I'll be putting my course on the market - and telling people that it's a toolkit, not a bible. Is that an Agile principle?
Comment by Hugh Neill posted on
But surely ‘Agile’ is an ambition, and is not (or should not be, in the first instance) a methodology.
I came into the Government services from a SME business manager background. Whilst there I’d written Rapid Application Development (RAD) systems to give me competitive edge (in 1988 few if any SMEs had or could afford stuff like that so.....). My guiding principles were:
• The market changes, the business demands change, and in ways you cannot entirely foresee
• The customer is king
• The market (and my application) is driven by 3 things: fear, need and greed
• IT must deliver for my business substantially more than what it took to build it, and it must not cause me to put my business on ‘hold’ whilst being implemented.
As I developed my software, the world of computer programming around me moved on from procedural languages to object orientated programming (OOP). The buzzword was ‘event driven’ applications. OOPS is synonymous with MS Windows: instead of coming out of your spreadsheet application where you were working on a budget in order to load up your database and answer a customer phone call, you simple clicked across from one application to the other. In other words, you became more agile. However, underneath your operational agility there still operated a series of processes that followed strict rules, that communicated with each other in clear unambiguous ways as each handed over data to the other for processing and then receiving back the results of that processing. The trick, the HolyGrail in programming, was to make each process as universally relevant, flexible, reusable and responsive to changing application needs as was possible, and to have a well classified and documentated library of them. With this investment, you could handle a lot of change.
I can’t help but feel there is a lesson for PPM here. After all, wasn’t the concept of a ‘programme’ developed so that a collection of projects could be created and/or discarded in order that their various outputs would collectively produce the desired outcome whilst the programme was experiencing changes in the world around it?
If I had to make an observation, it might be that a healthy apprenticeship in a market driven (SME) world could provide a useful adjunct to formal PPM qualifications, if project management is required to deliver the ambition for agility.
My confession? I feel like I've practised PPM for years, but without a single formal qualification. OOPs!
Comment by Jim Frewin posted on
Mike
Absolutely spot on! Totally support that agile is a mind set and a way of that can help transform organisations, departments, teams and individuals.
One of my biggest concerns is that we persist in trying to teach people about agile software delivery methodologies and agile language and then expect them to have an agile mindset. Agile can and should be much more that just software delivery. I understand why software was our initial focus but is it now time that we moved on from there? Changing mindsets to being more agile can lead to positive culture change across organisations, I have seen and experienced this.
We talk in terms of a NEW agile world which can make some people a little anxious about agile yet like software delivery this mindset challenge can and should be iterative. I am often asked “ if agile really isn’t just a set of rules but is a mindset then how do we develop this mindset across our organisation and Government”. It would be great if you could help me understand how we are doing against this mindset challenge?
My confession – Prince 2 (2008).
Comment by Kay posted on
I don't think anyone disagrees that digital services are best delivered using an agile methodology, and I agree that you shouldn't try to do a bit of one and some of the other ... I have a bit of a concern that your teams out in the departments are evangelising that agile should be used for 'everything' ... where you say pragmatic, they are dogmatic, and disrupting delivery in doing so!
Comment by Nathan Nelson posted on
Great post! I have unfortunately been involved with a couple large enterprises who "want" to change to Agile, but revert to type as soon as there is any pain associated with the transition.
Start-ups and thankfully government - they get it, old IT enterprises don't.
I think a huge part of any Agile project needs to be a re-education on not just the benefits of Agile, but the intricacies of the full change in practice and in mindset. From development and delivery right through to legal and procurement. The CEO, CTO, stakeholders, devs etc. all need to know and be on board as advocates. Without this, the half / half - Agile with the "safety net" of waterfall wrapped around it rears it's ugly head and inevitably leads to a mangled hybrid that nobody is happy with.
Comment by Julian dos Remedios posted on
I do agree with all of this. In a big organisation i'm still always asked for prince2 things as this is a comfort zone. being an expert helps to refuse. Delivering products before even appearing on a portfolio plan is the best bit, sorry i don't need a pid as we've already delivered...we don't need a risk register as we manage these as we go along. It is getting better and the exemplars and emerging digital work shows how it can be done quicker and better. This is, in old terms, evidence based policy making as there aren't many examples of the old approach delivering transformation. Prince2 worked well for me doing an office consolidation and new site refurb but Agile enables us to be Transformational.
Comment by Mike posted on
Excellent article. I tweeted "Agile isn’t a process, it’s a mindset." at the GDS team only the other day after yet another run in with a GOV.UK website that had poor grammar, broken links and a single line comment box!