Clickbait-y title or not — I’ve got some stern truths for you. Agile practices do not make teams Agile.

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 prioritized 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.

The Agile Manifesto

Some of the world’s most successful organizations that have appeared in the last 20 years are self professed Agile organizations. 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?

That’s 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 that failed to deliver. It could be that the C Level don’t feel like they ‘move’ fast enough — or it could be that there’s enough people fed up with 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’re 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.

Big companies that fail to innovate

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 halfway through what we’re doing, and we need to throw away weeks of work.

Soon enough there are murmurings in the business that Waterfall allowed us to deliver things in a better way and that ‘Agile’ isn’t all that it is 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 prioritized 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 organization. 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 it is 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 the products forwards.

Instead — Agile is a Philosophy about enabling positive customer change that drives business value.

The transformation starts with an Agile Mindset and not with the Agile practices.

Being VS Doing

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 worked in several agile teams in my career, and every single one of them has done Agile differently — and that’s 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 an opportunity to actually 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.

#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 read the customer statements. Invite them for system test workshops.

Everyone should be involved with seeing their users of their products interact with them.

#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.

Communicate on what’s working and not working for the team.

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.

Communicate on the positive impact that your changes have driven, along with the ones that delivered no value.

#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 or dislike this article, use the comments below to speak up.

Read other post related with the subject:
https://luism.co/scrum-twice-the-work-in-half-the-time/

Story point estimates, five reasons not to use it!