Businesses who conduct any form of software development are increasingly “doing agile“. Typically this means they’ve replaced traditional waterfall project management within their “IT department” to probably Scrum or SAFe^[1]For the sake of brevity I’m skipping over why SAFe is a step backwards and only entrenches problems. That’ll need a post all to itself., within smaller and larger orgs respectively.

A few people will go on a course, and on return set up a Jira / VSTS board, book a morning meeting titled “Stand Up”, and the release schedule is changed from Quarterly to Fortnightly overnight. On the surface, this is a step in the right direction^[2]It isn’t..

If agility is a concept restricted to just your technical teams, and not your business as a whole, then you’re not actually “doing agile”.

A conversation I routinely have with friends, (ex)colleagues, and the like, is about how tired they are because of the level of extra effort required to affect change within their organisations. This is across all shapes and sizes, big/small, paid/voluntary, public/private.

The conversation will eventually meander through two topics:

• How long it takes to make a change – start to finish? From concept, to delivery, not just development.
• How much resistance occurs along the way? Do they feel that it is their own personal determination that makes change happen, instead of something which is embraced?

Complaining about work and feeling helpless isn’t new, and given that it is the plot for three of the biggest films of 1999 I’m not pretending like this is some sort of revelation. However, the frequency of answers^[3]My sample is self-selecting because this conversation doesn’t come up in relation to organisations where the answers are “no time at all”, and “very little” being “a long time, could easily be a year or more“, and, “oh, so so much, I’ve given up more times than I’ve failed, let alone succeeded” coupled with the clear frustration expressed is something which leads me to believe that while this isn’t by any means rare, or novel, it’s actually an accepted, expected and purposefully constructed scenario by the organisation itself.

This is often done under the presumption that enough approvals and controls will ensure certainty of two things:

1. Nothing bad will happen
2. Only good things will happen

A fundamental aspect of doing agile is embracing uncertainty. To embrace uncertainty you need to be able to make changes quickly, and learn from them.

To make changes quickly, individuals need to be empowered with authority and responsibility delegated. They must be able to make meaningful change without arbitrary approvals and sign off. Equally, they must be responsible for the impact of those changes. That responsibility must be against quantitative targets, not subjective opinions. If they fail, they fail – now learn from it, and try again.

If your organisation can only do things quickly when the house is on fire, and you use executive authority to bypass red tape, then you have systemic issues which need to be addressed. Because if they aren’t, then you better be absolutely right in every decision you make, otherwise you’ll lose to a competitor who can move faster than you and found out the mistake long ago.

It can’t be left up to the determination of individuals.