Stop ‘delivering’ software with Agile — it doesn’t work
Clickbait-y title or not — i’ve got some stern truths for you.
Let me start by asking you a question.
Are you delivering software with Agile methods?
Yes? Great! I imagine you’re doing the following?
- Do you work in some kind of set phases, either in sprints that last anywhere from 1 to 4 weeks, or work continuously?
- Are you working from a backlog or a prioritised to-do list?
- Are you regularly releasing changes to your customers?
- Are you responding to how things change?
For a lot of people I speak to — when they’re following these they think they deliver software with Agile.
But they’re not working in an Agile way.
Some of the worlds most successful organisations that have appeared in the last 20 years are self professed Agile organisations. However we have all seen a lot of tech centres within orgs work Agile and fail to actually deliver significant value to the users. So that begs the question, why should we use Agile to deliver software?
Thats because we probably shouldn’t be using it to deliver software.
Why Agile Fails to deliver software
Agile fails for 2 fundamental reasons:
1. We try to use it as a change management methodology
This typically happens when we might have been bitten by a big project/s that failed to deliver. It could be that the C Level don’t feel like they ‘move’ fast enough — or it could be that theres enough people fed up of producing 50 page requirement documentation that do nothing but increase our printing and recycling costs.
Agile fails when we pick it up as a methodology and only focus on delivering software with it.
This usually happens when someone in the business proclaims:
All of a sudden we are forming scrum teams. We following Agile best practices like sprints, daily stand-ups and instead of producing requirement docs we’re writing these weird and unusual things called User Stories with Acceptance Criteria.
We’re all able to pat ourselves firmly on our backs for a job well done. We’ve transformed our business — we are Agile.
But we don’t notice any difference in what we were doing before. Those needles we are trying to shift — they’re not moving.
We’re still working against big projects and we only get recognition when we release something.
We’re still getting derailed because of time spent on environmental issues. That old problem of moving goal posts? Well we’ve got stakeholders coming in and asking for things right now or the original scope changes half way through what we’re doing and we need to throw away weeks of work.
Soon enough there is murmurings in the business that Waterfall allowed us to deliver things in a better way and that ‘Agile’ isn’t all that its cracked up to be.
2. We never ‘finish’
I’ve seen tons of articles about how agile is a disaster because of it causing burnout and fatigue within the teams. The most noise i’ve seen from this is mainly from developers who feel like they never have the ‘downtime’ that waterfall projects produce at the end.
The general feeling is that teams work relentlessly from sprint to sprint — or if they’re working Kanban, off a never ending backlog with no end in sight.
Everything is always prioritised as important — so they never get a chance to think and because they’re releasing in smaller increments the versioning is just insane. They’re currently on MVP v64.21.
Everyone has gone mad: the Designers have started wireframing by etching it into the windows in the office, the Developers have started shipping out code by writing it on flipchart paper and stapling it to tree-branches. Worst of all — the Product Manager has run out of Post-its and there’s not a sharpie to be found anywhere.
When either of these 2 things happen, maybe your best talent starts to leave the organisation. Maybe your product fails to create change for its customers and you stop growing/start shrinking. Maybe your org decides that this ‘Agile’ thing isn’t really for them and moves back to Waterfall.
Agile fails because its our belief that it is a software delivery methodology.
So how can we make Agile create successful change
Notice some subtlety there?
Create successful change
Agile is not about delivering software. It isn’t a methodology with a rule book that we can follow in order to push my products forwards.
Instead — Agile is a Philosophy about enabling positive customer change that drives business value.
Lets start by recapping the core values of the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Lets break this down and look at each individual section:
Individuals and interactions over processes and tools
In Agile — we need to value our individuals and the interactions over our processes and tools that we’ve brought in. I’ve written before about this and it’s been my most successful Medium article so far:
We also need to stop our processes holding us back too. Just because what we’re doing isn’t strictly by a book someone has on their desk — it doesn’t mean we shouldn’t try it to see if it works for us. I say this a lot but:
Every business is different and every team in every business is different. One size doesn’t fit all.
Working software over comprehensive documentation
This value means we focus on deliver actual working software out to our users vs creating humungous documentation.
This doesn’t mean that we don’t document — which is how some teams see it.
Instead we document what we’re doing and what we have learnt, whilst maintaining a focus be on actually shipping beneficial change out to our user base. I shouldn’t need to produce 50 pages on the ‘what’ we are embarking on building before I start to understand how it affects our users.
The second part to the working software part of this value is that we need to focus on the fact that it ‘works’. And this is in 2 elements:
1 - Users can do what they need to do in it
Is it usable, does it act and behave in a way that users expect it to?
2- Its relatively bug free that users can complete their tasks with it
Are users able to do what they need to do without any hinderance?
Customer collaboration over contract negotiation
Your users are important. There’s quite possibly a million+ articles on Medium alone about why you should listen to your users and build your Products based off what they’re telling you.
You need to work with your users to understand that you’re building the right thing for them. This isn’t Field of Dreams.
Just because you build something doesn’t meant they’ll use it.
If you build the right thing for your users — ultimately the change you deliver will have more positive outcomes for your business.
Ultimately who is paying your wages? Your users — so listen to them.
Responding to change over following a plan
We’ve all seen this diagram:
This is often used to indicate that we should learn as we build and I whole-heartedly agree with that — but what a lot of people don’t consider is that maybe we should have stopped at the bicycle.
If our goal was to enable people to get from A to B, perhaps the bicycle is the best possible method. Maybe we’d love to have a car but right now its not the thing we should be spending the time on. Maybe building the engine adds another £500k to the build cost and thats just not viable right now.
In the Agile manifesto we respond to change by paying attention to whats happening with our Products and how our users are interacting with them.
This value in the manifesto is not used as a get out clause for stakeholders to constantly change direction on you — no matter what some might think.
Building a culture around agility
The first and foremost important thing about building a culture around agility is for us to stop thinking about delivering software with it.
We need to focus on delivering beneficial change to our users.
There isn’t a perfect way to do Agile. I must have worked with 30+ teams in my career and every single one of them has done Agile in a different way — and thats absolutely fine.
But if you follow these steps — you can start to create more agility for your customer outcomes.
1: Create individual interactions within your team
Use the standups, planning sessions and retrospectives as a opportunity to actual discuss how you’re doing against your goals as a team of people.
Focus on building your team vs it being a group of people working in a similar area. Christina Wodtke has just given a great talk on this at Mind the Product: https://www.mindtheproduct.com/2018/07/reboot-your-team-by-christina-wodtke/
2. Start figuring out how to build up autonomy and trust for your team
Start acting as a single unit towards an outcome. Report on how you’re doing against that outcome and align your outcomes towards company goals.
If the most important thing for your company right now is to stop customer churn, communicate on how your changes are affecting that.
If you’re having a positive impact — you will win trust and autonomy to keep doing a good job.
If you’re not having a positive impact — it forces the question about what it is you’re focusing on and why. This is good and again will win trust for the team.
3. Involve your users frequently
Encourage your whole team to go sit in the contact centre and listen to calls. Get them to dive into your UX research tools and read the customer statements. Invite them along to guerrilla user testing in your local cafe. Everyone should be involved with seeing their users of their products interact with them.
There’s a big movement out at the moment to create ‘user fridays’ where every Friday users are brought in and the team works with them. This is an idealistic view and its great if you can do it — but start small with the resources you have. The main point i’m making here is that its not just up to one person on the team to understand how the changes the team are producing are affecting the users.
4. Communicate, communicate and communicate
Sharing is caring. Always talk about what you’re doing and why you’re doing it, both internally within the team and externally:
Internally within the team
Communicate on what it is you’re focusing on and why at the moment. If we need to focus on the conversion rate within our checkout — why are we doing that?
Communicate to the team why fixing that bit of tech debt just doesn’t quite make sense right now.
Communicate on whats working and not working for the team — has someone done a stellar job this week and needs recognition.
Communicate on what affect the changes the team have worked on have done to the user base.
Externally to the business
Communicate on what you’ve been working on and why you’ve been working in it.
If the team had to spend 5 days ironing our trunk problems after a branch merge — communicate on that.
Maybe you had to down tools for a sprint just to clean the bugs up in your backlog as it had got unruly.
Most importantly — communicate on the positive impact that your changes have driven along with the ones that delivered no value. When you communicate on the ones that didn’t behave as expected — tell people what you’ve learn from it.
5. Build learning and experimentation with your methods into your Agile process.
Agile encourages us to constantly learn — but we should also be actively encouraged to experiment with how we are going about things. Sometimes we’ll bring something in and it won’t work — but other times what we suggest will massively benefit how we’re doing thing.
6. Finally — Focus on delivering change and not software.
Measure your success on the outcome that your changes are having for your customers and not on the dates you ship out your software.
The org won’t care that you delivered something on the 1st of March if it did nothing to improve your offering for your customers.
By starting to follow these 6 tips you’ll slowly but firmly start to actually act more Agile. It’ll take time, but keep investment in your practices. If you ever reach 'nirvana' — start asking yourself bigger questions. There’s always room for improvement.
If you liked this article, give it a clap by tapping on the clap icon below or by sharing it. This encourages me to write more articles.
