Agile - more haste less speed
Anyone who’s ever been part of a prioritisation session will be familiar with the phrase “I need it yesterday”. Fortunately, most stakeholders eventually admit that the laws of physics can’t be broken, and relent.
Nevertheless, stakeholders - and the people who report to them - will always be excited at the prospect of getting stuff faster.
It follows that the easiest (and most common) way to sell Agile to senior stakeholders is by pitching it as being faster than existing methods: “We’ll give you twice as much in half the time!”
As soon as this conversation takes place, the bar is set. Expectations are high, and some people’s careers are riding on whether or not these goals can be met.
Agile is not magic
An Agile transformation is not some sort of magical ritual that endows developers with supernatural coding abilities.
New ways of working need to be learned and understood, and changes in accountability and hierarchy have to be digested.
It requires training and support at a level that the IT department probably hasn't seen before. In other words: it doesn’t happen overnight (and it’s not free!).
Things can go wrong
When management is mis-sold Agile as being instantly faster and essentially free, things go wrong. It’s not unheard of for every team to be given the ‘Agile starter kit’: A whiteboard and some post-it-notes, and to be left to just get on with it and please do hurry up.
Given this huge pressure, the features probably will come, but they’ll be rushed: they'll fail to meet requirements
All the while, managers hover around eagerly anticipating new applications and features to flow out of the teams. Given this huge pressure, the features probably will come, but they’ll be rushed: they'll fail to meet requirements, be bug-ridden and built in such a way that they’re hard to change.
The teams will be unhappy and will probably end up resenting the new way of working, especially if they’ve seen some of their colleagues leave during the transition. Does this sound like an ‘Agile’ way of working to you?
So what is Agile actually about?
I’ll always recommend going back to the 12 principles – there’s nothing there about being ‘fast’. Release early and frequently, yes, but only release working software.
What the principles do talk about is customer collaboration: creating high-quality software and giving teams the support and resources they need to build it.
Agile is all about satisfying customers, both internal and external to the organisation. To satisfy your customers, you need to focus on quality: quality of the relationship between stakeholders and developers, quality of the code, quality of life for developers, and so on.
No matter how good your developers are, if you give them garbage requirements, they’ll create garbage software.
We can think about quality software in two ways: Building the right thing, and building the thing right.
Building the right thing
To build the right thing, you need high-quality requirements and continuous feedback from customers.
Agile simply doesn't work without empirical information. No matter how good your developers are, if you give them garbage requirements, they’ll create garbage software.
This tends to happen when so much pressure is put on teams to produce things quickly that they start to believe there isn’t enough time to do proper analysis on requirements and user stories.
You don’t have to create a hundred-page requirements document, but you do need to take time to engage with your customers about what they actually need, and follow up on this regularly.
Building the thing right
Building the thing right is equally important. Rushed teams will take shortcuts, sacrificing quality. This adds hidden costs in the form of fixing bugs, paying back unnecessary technical debt, and doing complicated reworking when something doesn’t meet the customer’s requirements.
The main benefits of Agile are increased customer satisfaction and much greater efficiency from reducing defects and wasted effort
To be flexible, you need to build software that can be changed with minimal cost – this means building robust and high-quality software. It isn’t easy: it takes time, practise and discipline.
The main benefits of Agile are increased customer satisfaction and much greater efficiency from reducing defects and wasted effort. Those alone will provide a huge competitive advantage to any IT department or digital team.
Make haste slowly
So, does all this mean that Agile is slower than traditional methods? Not at all. With high-quality software, you can make changes very quickly, but only when the whole platform is built so that it doesn’t fall over when someone tries to change the colour of a button.
Speed doesn’t come first, but if you do things right, it does come. Once the quality is in place, you can then really put yourself ahead of the competition by releasing a new product or adding a killer feature in only a few weeks, or even days.