Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
When Agile fails on a massive scale publicly
|
So here’s this report on the British government’s impending failure of a system called “Universal Credit” which is a way to manage welfare payments in real-time and through a unified entitlement program to lower costs and streamline the distribution process.
Unfortunately, signs are that it is a troubled project even despite the fact that they used “Agile” methods:
In fairness to Agile, it looks as though the method was adopted more in “sprit” and as a ruse, to get the public to think that they were going to use a modern project management method know to deliver software projects efficiently. As the author states, Agile “has been treated as a silver bullet – not as what it really is – just another design methodology – while much of what is supposed to happen with an agile software development project – especially regular and repeated testing of prototypes - has been conspicuously absent.” So of course their decision is to go back to a more traditional approach for the back-end and to use Agile for the front-end, customer facing portions of the system:
Though this will be perceived as an Agile project that failed on a massive scale, one could also view Agile as a method that allowed the failure to be noticed quicker than if they had used a more traditional approach.
Sadly, I’m not so sure if this will build confidence in the public’s overall perception of the government’s ability to deliver projects though.
So here’s this report on the British government’s impending failure of a system called “Universal Credit” which is a way to manage welfare payments in real-time and through a unified entitlement program to lower costs and streamline the distribution process.
Unfortunately, signs are that it is a troubled project even despite the fact that they used “Agile” methods:
Universal Credit is also the world’s biggest ever “agile development” software project and a massive financial and social (and hence political) risk for the government. Unless delivered on time and on budget then the consequences are grave – some of the most vulnerable people in society could be left literally destitute, with all that entails for their personal welfare and social order.
Yesterday the government – at least part of it – finally admitted in public what the rest of us have known for a long time: that the project is in deep trouble.
Universal Credit is also the world’s biggest ever “agile development” software project and a massive financial and social (and hence political) risk for the government. Unless delivered on time and on budget then the consequences are grave – some of the most vulnerable people in society could be left literally destitute, with all that entails for their personal welfare and social order.
Yesterday the government – at least part of it – finally admitted in public what the rest of us have known for a long time: that the project is in deep trouble.
In fairness to Agile, it looks as though the method was adopted more in “sprit” and as a ruse, to get the public to think that they were going to use a modern project management method know to deliver software projects efficiently. As the author states, Agile “has been treated as a silver bullet – not as what it really is – just another design methodology – while much of what is supposed to happen with an agile software development project – especially regular and repeated testing of prototypes - has been conspicuously absent.”
So of course their decision is to go back to a more traditional approach for the back-end and to use Agile for the front-end, customer facing portions of the system:
Some steps have been taken to try to rescue the project. The back end – the benefits calculation – has reportedly been shifted to a “waterfall” development process – which offers some assurances that the government at least takes its fiduciary duties seriously as it should mean no code will be deployed that has not been finished. The front end – the bit used by humans – is still meant to be “agile” – which makes some sense, but where is the testing? Agile is supposed to be about openness between developer and client and we – the taxpayers – are the clients: why can’t we see what our money is paying for?
Though this will be perceived as an Agile project that failed on a massive scale, one could also view Agile as a method that allowed the failure to be noticed quicker than if they had used a more traditional approach.
Sadly, I’m not so sure if this will build confidence in the public’s overall perception of the government’s ability to deliver projects though.
|
Posted on: June 09, 2013 10:44 AM
| Permalink |
Comments (3)
Kicking Scrum to the curb with Kanban
|
ThisThis article on the Scrum Alliance site has an interesting take on putting aside Scrum when your requirements change so much that you need Kanban to stabilize your release:
This article on the Scrum Alliance site has an interesting take on putting aside Scrum when your requirements change so much that you need Kanban to stabilize your release:
It’s a good point to keep in mind that in a situation where requirements keep changing that you need a method that limits work rather than one who’s focus is on releasing the plan.
As is always the case with any method or framework, you use what’s the most appropriate and optimal for your project and not because you have a pet method or framework you want to advocate or evangel
This article on the Scrum Alliance site has an interesting take on putting aside Scrum when your requirements change so much that you need Kanban to stabilize your release. As the author states:
From my experience here (and yours will no doubt be different), Kanban is useful when requirements and priorities change quickly and often. If we truly value the principles of the Agile manifesto, then we should welcome changing requirements, even late in development; but in my opinion, Scrum is only good at this when we can handle changing requirements every one to two weeks (I avoid saying four weeks!).
This is why Kanban is the unofficial preferred framework for maintenance staff, as it is more concerned with limiting work in progress than it is fulfilling a release plan/backlog.
It’s a good point to keep in mind that in a situation where requirements keep changing that you need a method that limits work rather than one who’s focus is on releasing the plan.
As is always the case with any method or framework, you use what’s the most appropriate and optimal for your project and not because you have a pet method or framework you want to advocate or evangelize.
As is always the case with any method or framework, you use what’s the most appropriate and optimal for your project and not because you have a pet method or framework you want to advocate or evangelize. articleThis article on the Scrum Alliance site has an interesting take on putting aside Scrum when your requirements change so much that you need Kanban to stabilize your release:
It’s a good point to keep in mind that in a situation where requirements keep changing that you need a method that limits work rather than one who’s focus is on releasing the plan.
As is always the case with any method or framework, you use what’s the most appropriate and optimal for your project and not because you have a pet method or framework you want to advocate or evangelize. on the Scrum Alliance site has an interesting take on putting aside Scrum when your requirements change so much that you need Kanban to stabilize your release:
It’s a good point to keep in mind that in a situation where requirements keep changing that you need a method that limits work rather than one who’s focus is on releasing the plan.
As is always the case with any method or framework, you use what’s the most appropriate and optimal for your project and not because you have a pet method or framework you want to advocate or evangelize.
|
Posted on: June 02, 2013 10:44 PM
| Permalink |
Comments (5)
Scaling Agile with Scrum and Kanban
| Here's a good recorded webinar on how to scale Agile with Scrum and Kanban:
This topic is usually discussed from the perspective of typical small, co-located Agile team, but this webinar looks at it from how to scale it using Scrum and Kanban. Check it out! |
Posted on: May 19, 2013 07:49 AM
| Permalink |
Comments (1)
Why can't organizations just become more Agile?
| Sure, we like to think we can control the successful outcome of our projects, but as we all know, there are often times organizational barriers that are just too hard to overcome. This article on InfoQ list some common barriers that's helpful to keep in mind:
What barriers have you come across not listed above and what did you do to overcome them?
Ineffective use of the retrospective
Inability to get everyone in the planning meetings
Failure to pay attention to the infrastructure required
Bad ScrumMasters
Product Owner is Consistently Unavailable or There are Too Many Owners Who Disagree
Reverting to Form
Obtaining Only "Checkbook Commitments" from Executive Management
Teams Lacking Authority and Decision-Making Ability
Not Having an Onsite Evangelist for Remote Locations
A Culture that Does Not Support Learning
Denial is Embraced Instead of the Brutal Truth
People will always put their own interests ahead of the interests of the group.
People are self-interested
Commercial production decisions are based on rational expectations.
Karl Popper's "First law of collective action". You can never get more than 5 people to agree on anything
|
Posted on: May 12, 2013 09:37 AM
| Permalink |
Comments (3)
When a Scrum-Master acts more like a Scum-Master
| Software development and project management are very serious technical topics, so to add a little levity to your day, I present this video of how a "Scrum-Master" actually acts more like a "Scum-Master" (please note the semantic differences!):
Enjoy! |
Posted on: May 06, 2013 09:07 AM
| Permalink |
Comments (1)