Another reason why your Agile implementation is failing
Agility. Meet bureaucracy.
Although you’re supposedly working in some kind of Agile methodology, you’re probably still being controlled to a fixed cost, fixed quality, and fixed deadline, which sounds a lot like waterfall to me.
Many Agile implementations are masquerading under the false pretenses and misguided notions that you can implement the jargon and diary-commitments from Agile frameworks and call it a day, all the while attempting to control everything like a traditional waterfall project.
And that’s fine — if you want that amount of control over the project or product then just call it what it is, don’t brand yourself Coca-Cola but deliver Jimmy’s Cola Drink beneath the label.
It’s important to be transparent about what you’re actually trying to achieve and how you’re going about it, because the fact of the matter is that you can’t have set deadlines, backlogs, and budget, and then consider yourself Agile and able to appropriately respond to feedback in an endless loop of continuous improvement if you are unable to respond to change.
By their very nature they are incompatible!
And that’s where one of the many difficulties arises — when decisions around priority are to be made.
When you’re a Big Bang waterfall project (technical term), it’s slightly easier to make decisions around bugs, though you feel dirty and guilty all over when you say things like “We can go live with this.” (And you should feel guilty.)
But that’s fine, to an extent. There’s a time and place where this is acceptable — you can’t do it all at the same time. If you know the limitations of your product, you can manage the impact.
But, if you’re doing some Italian meatball methodology (30% agile, 10% lean, 10% SAFe, 50% waterfall, and don’t forget the salt and pepper), then you’re going to come up against production issues.
If you’re stuck to a rigid backlog, then how do you respond?
And, regardless of methodology, you’ll always come up against new requirements for improvements or new features overall.
How do you prioritise change against The Plan?
If you believe you can control time, quality and cost, then it’s really difficult because your budget holder acts like a broken record telling you that we agreed on a scope and a deadline and cost, while you’re banging your head against the wall, screaming.
It’s like being a firefighter called to an emergency with everyone around you telling you that you need to get to the house at the end of the street because it’s the one that’s on fire, but your Captain tells you that you need to get through every other house on the street first!
The only thing that happens then is that the users get soaked with functionality they didn’t need right now (or at all) and keep getting burnt by the one thing that needs solved. C’est la waterfall.
This is one of the toughest things about going agile in legacy organisations — managing budget.
The thing is, there’s no such thing as a standalone project any more. Or at least there shouldn’t be if you’re managing the software you create properly.
A project is a once-and-done affair to a strict timeline, budget and scope. What a project means is that you’ve succeeded before you’ve begun — at least that’s what the PM and PMO believe, “but we put together a beautiful Gantt chart and laid out all the costs on a spreadsheet, why didn’t it work?!!!!!”
Now, what you’re actually doing, or at least you should be, is managing products. Products are things that provide value and utility to somebody, somewhere, whether it’s your customers or your colleagues.
Take a car as an example. You don’t just cost the initial purchase of a car and call the project done. No, you’ve got annual MOTs and Services. You’ve got the cost of petrol, cleaning, general maintenance, full breakdowns, insurance — god there are so many costs.
Then you’ve got improvements. Maybe you need to replace a fan belt or get winter tyres.
But your project is delivered — you can’t go asking for MORE MONEY!
Let’s compare this against a software product. The purchase of the car is the initial development and delivery to customers. Your MOTs and other costs are operational costs assumed in the general running and maintenance of your product. Then, your fan belt is a bug and the winter tyres are a new customer feature request.
If this were a project, you’d spend three months begging PMO to create a new small-change project and allocate budget and people to buy winter tyres and fit them.
Now, look at the solution as a product with ongoing operational budget to maintain and improve the product! The bug and feature just go into the backlog and are tackled when we get to it based on an agreed set of priorities.
And if the feature is relatively large and you need more capacity? Well, that’s where you have a project! Small scale projects with a clear deliverable as an addition to your OPEX budget with a CAPEX flex!
Then, once the project is delivered, the CAPEX flex is reduced but your core operational team continue to fix bugs and make improvements and ADD VALUE.
Almost seems too simple, right?
Well, there’s a big issue in the way we compare agile startups or mature agile organisations like Spotify to incumbent institutions like banks. When you’re a startup, your whole business is generally the single product, whereas an incumbent could have HUNDREDS of products.
So, while Spotify splits out people into Squads of feature teams, you could think about setting up dedicated teams to look after families of products under single backlogs that don’t end.
So, what?
The work only ends when the product no longer provides value, and when that happens you retire the product completely or pivot.
Until then, leverage the power of continuous improvement and continuous delivery and continue to make things better.
Don’t deliver once and call it done. It’s just plain not good enough.
