It begins with a simple request: “We need to know when it will be done.” Or “When there is an Agile-savvy manager? Our velocity needs to be higher.”
But the more I look the more it appears the development team are not really that bad; in fact, they might actually be good. And, if you doubled team productivity overnight it would not make a big difference. The problem is elsewhere.
Sure, the development team could be better in many ways but simply coding faster is not going to solve the problem.
The on-ramp and the off-ramp are in need of improvement: the work intake and the work delivery mechanism – entry ramp (getting stuff in processed) and exit ramp (getting it out the door) – are often more important.
As they say: its déjà vu all over again. I see this again and again. In my mind’s eye turning requests into working software is a freeway, a motorway, an autobahn – a “controlled-access highway” to use a technical term. Each piece of work is a car.
Most of our attention goes on the cars/work speeding down the lanes, that is where we assume time is spent. That is where most of the team is working. That is where we direct people to look for problems.
If all goes well the work/car moves rapidly from one place to another.
Sure things go wrong on that journey, in coding, sometimes other pieces of work get in the way, sometimes something goes wrong and there is a pile up with work/cars queuing behind. And sometimes the best way of improving the overall flow is to limit work in progress or reduce speed limits.
But the actual speeding down the highway part is but one of three essential elements. Frequently this is not where time is lost, and even though work can be unpredictable, it is not the most unpredictable part of the work.
It is fairly common for work to spend most of its life waiting to enter the system – the on-ramp, how cars get on the highway and how work enters the development processes.
And there is the off-ramp – how does work leave the system and reach the customer? – after cars only join the highway when they are coming from one place and want to get to another.
Most people working in the system see their job as driving cars and ensuring that a particular payload is delivered to the destination.
Who looks at the overall system? Who manages the highway? Who optimizes the flow? This is where I see my work.
It is not enough to ensure a piece of work is delivered. It is not enough to ensure the cars are going fast. One has to see the whole system. Usually the on-ramp and off-ramp require far more work than the actual highway itself.
In other words: it is not about ensuring any one car arrives once. It is about ensuring the system for delivering cars works effectively. While the highway journey gets the attention, the on-ramp and off-ramp are often far more important.
It is very common to find that development teams are working pretty well, but when work is “done coding” it queues to get through testing, queues to get into a release, and queues to be released. In fact, it is almost normal in teams that work spends longer “getting out the door” than it spends being done.
The continuous delivery movement has done a lot to improve this, and the best teams have streamlined and automated this part. But problems remain. I will just mention two.
ONE: I just said, “the best teams.” The best teams are few and far between. Yes, they get lots of attention, but most teams are a long way from this.
It is not uncommon to find that teams consider some continuous delivery processes madness. I floated the idea of branchless development to a team this year and they took it as a sign that I did not understand their work. The idea that you might not use source control branches appeared like a naïve beginners’ mistake.
TWO: where do you put testing? If testing is considered a special activity that must happen as part of a release process, then it occurs on the off-ramp. That off-ramp has limited capacity and any problems have big knock-on effects – it is very risky.
However, testing can be considered part of the main highway experience. Developers can work to a high standard an incorporate practices like TDD and BDD which lessen the need for testing. Formal testing – probably by professional testers – can be positioned before the off-ramp if you design the highway/workflow correctly.
The intake process, the requirements process, the work-before coding, work that is normally done by Product Owners/Product Managers or Business Analysts. This can cause even bigger hold-ups than the off-ramp.
I have written before about the fear many organizations have of actually coding. As a result, work is held in perpetual review, estimation and planning before it is allowed anywhere near a coder.
Another cause of delay is the product backlog: in many places this is a bottomless pit of work to do. Every few weeks the Product Owner shifts through the backlog selecting a few pieces of work to get done. Most work does not get done and falls to the bottom. It is unlikely to be done but gets in the way and distorts metrics. As a result, most work spends most of its life cycle waiting to be done, waiting to get onto the highway.
There is a natural (and good) tendency to focus on the work in hand, to think “if I can only get this piece of work done…” Like Orwell’s Boxer pledging in the book Animal Farm: “I will work harder” to any problem. (Note: there are plenty of non-team members prepared to stand on the sidelines to say “If only they did work harder”).
Animal Farm is a satirical allegorical novella written by George Orwell, first published in England on 17 August 1945.
The fable reflects events leading up to the Russian Revolution of 1917 and then on into the Stalinist era of the Soviet Union.
The book tells the story of a group of farm animals who rebel against their human farmer, hoping to create a society where the animals can be equal, free, and happy. Ultimately, the rebellion is betrayed, and the farm ends up in a state as bad as it was before, under the dictatorship of a pig named Napoleon.
Boxer represents the peasant workers of Russia. They were exploited by the Tsar Nicholas II who ruled from 1894 until his expulsion in 1917. The workers were kept in a position where they never earned enough money to pay for food or accommodation. The Revolution of 1917 sought to address this problem but only led to more hardship and starvation under the rule of Stalin.
Boxer, a horse, is a tragic hero. He is shown as the farm’s most dedicated and loyal labourer. He is a hard worker, strong and caring. His favorite saying is “I will work harder.”
Unfortunately, he is too loyal: the pigs take advantage of this and work him until he collapses.
It is not enough for any one person to work harder. It is a system: the on-ramp, the highway and the off-ramp all need to work together.
Only looking at the whole do these things become clear. Improving this flow requires a different set of skills to those of writing code and testing – of course there is overlap in skills and of course people can learn; but again, if one simply pledges to “work harder” and write better code the improvement will be marginal.
Seeing the highway – the work flow – is something I would expect a development manager to do, and if not a development manager then the person I call an Agile Guide –and most of the rest of the industry calls an Agile Coach.
I am Allan Kelly and these are my agile-thoughts
2021 © London, England, UNITED KINGDOM by Allan Kelly
Allan Kelly wants software professionals to enjoy more fulfilling and satisfying work. He advises teams and managers on using Agile approaches to improve the way work is organised and requests are made.
Happier people and better ways of working make for more effective companies, greater value and competitive advantage.
Despite being dyslexic his desire to change the world has led him to write seven books such as “Business Patterns for Software Developers” and “Continuous Digital.”
“Succeeding with OKRs in Agile” is his latest one.
USEFUL? You can share it!