Stop ‘delivering’ software with Agile — it doesn’t work

Clickbait-y title or not — i’ve got some stern truths for you.

Photo by Jason Rosewell on Unsplash

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.

Author: James Whitman

Collect by: uxfree.com

Comment

Top