A couple of months ago the good guys at LeanKit asked me to explain how we managed to get to Continuous Delivery in PaddyPower while I was working there.
I was very happy to do that and wrote the piece as a Guest blogger on their site. If you are interested you can find it here.
It was a wet and dark morning in Dublin when I sat with team X for the first time.
I had been told: “Gus, these guys are struggling, they really need your help. They are always late, and everybody complains about the quality of their work, it’s bad, very bad”.
I expected a demotivated team of technically poor developers with its members playing video games or youtube videos instead of doing their job, but I was wrong.
No developer was slacking or pretending to work, on the other hand, I saw people with worried faces shuffling around, some listening to angry customers, some head down into code, some testing and quietly cursing.
To a newcomer, they looked super busy and doing their thing.
I perceived the first hint of trouble later in the day. I went to talk to some of them, just introducing myself and telling them that I was going to work with them to try to make their life easier. Each and every one of them was too busy to talk. All of them had something urgent, being a production issue, being a customer waiting behind their backs, or a release they had to finish by 5pm. Sorry, sorry Gus, I really can’t now, I have this blah blah…
I took it in and let them alone for the day. The day after, I kept on observing without saying a word. The amount of pressure that I saw applied on to these poor kids was frightening. In the same day I saw 8 different people go to the same developer and demand he finished something he was meant to have finished already. The requesters were different people and asked for 8 different things, all quite angrily.
The subsequent days, my observations stressed more and more this situation, the people were pushed over the limits and by trying to finish things quickly and relief some of the pressure were skipping steps and introducing new problems, new issues to work on, and so on.
I kept on observing and asking questions here and there, but the people saw me as somebody that couldn’t help them with the code, hence quite useless. I had to do something different.
On the 4th day, in the morning, after their standup, I told them to stop doing what they were doing and come and have a chat with me.
Believe it or not, It was almost impossible to get them off their seats.
They felt they could not leave the sinking ship, they needed to continue trying to flush the water out with their hands. Did I have a powerful drain pump and could save the boat easily? They didn’t have time to learn how to use it, they needed to keep on shovelling with their bare hands.
I eventually got them into a room. We had a retrospective. I disguised the retro to be something else, because I had heard from one of the developers: “we don’t do retrospectives anymore, what’s the point if we don’t have the time to change anything?”
That’s a very valid question. Very.
The team was obviously overloaded and didn’t have the maturity and the necessary negotiation skills to express that to their customers and stakeholders. They had reacted to the overload with what I call the “headless chicken approach”. It works like this: “Just do all you can, forget about quality, process, product, customers, just run for your life and even if your work product is terrible, people won’t be able to blame you, as you work like a donkey every day.”
Do you think this is uncommon? Well think again.
The first step we took was to visualise the work in progress. The guys were using Jira with no physical board and didn’t realise how much work they were really taking on. The board was scary, full scary I mean.
As the work came from many different products, another thing that we did was separating the products into different classes of service.
By doing this we immediately saw that one product had most of the tickets, why? We don’t know yet, but at least we are aware of it now.
After this very simple step the team members started having conversations that were beyond the need to finish MyNewFeature, they started looking at current priorities and talking about the whys of the bad situation they where in.
Then they started talking about experiments to fix it.
They were improving the system.
I looked outside the window, the sun had come out.
What were the 3 steps we made that enabled the behavioural change?
Just this small change had transformed a group of intelligent people acting like headless chickens into people that were trying to improve a complex system, not bad for a weeks work I’d say!
If you are curious stay tuned and I will tell you what happened next, no more chickens, I swear.
The new episode of the story of Team X is out
A few weeks back I asked this question on a very popular Agile and Lean LinkedIn Group:
10 years ago not many companies delivered value every month and Scrum really helped the industry with the concept of sprint. People started thinking in terms of vertical slices of value rather than systems and started to deliver value often, it was a great step forward towards agility.
Today most shops do 2 weeks sprints and it is commonly accepted that smaller batches are better than larger ones as they are less risky and also allow for earlier benefit realisation.
I understand how the concept of sprint has helped the industry become more agile and lean, but, and there is a but.
Why have sprints today? Why create artificial deadlines? Why create a minimum batch size, be it one week, two weeks or whatever it is?
If I am a mature organisation, I probably have cut delivery transaction costs and have a good strategy for continuous delivery and I am able to release whenever I want with little effort and risk. Why can’t I release when I have value to deliver?
Can anybody give me a valid reason for having sprints?
The topic became popular with a total of 35 thumbs up and 85 comments (including my replies)
Reading the answers, I am not only more and more convinced that sprints are unnecessary and dangerous artificial deadlines, but I am starting to think that in some agile practitioners thinking, the scrum guide has replaced the true reasons for agility.
If you have better reasons why we should always sprint, please add them as a comment, I am still hopeful I have missed something and want to learn.
The Work In Progress limit (WIP limit from now on) is one of the most powerful but counter-intuitive concepts I had the fortune to encounter in my work life.
When suggesting teams to introduce a WIP limit to their boards, I hear objections like “are you saying that doing less things at the same time is going to make you faster? You must be wrong? If I start 10 things I’ll finish earlier than if I can only do 2 at the same time!”
or “Working on one thing at the time only? That’s NOT efficient!”
It is indeed a counter intuitive concept, proven by the fact that most people object to it based on common sense.
You might say, why don’t you explain the reasons behind the value of WIP?
Don’t get me wrong, I am familiar with queuing theory, Little’s law and the relation between resource utilization and queue size, but these concepts are not something that can be explained easily every time that the objections are brought forward. Funnily enough, explaining them, is not really efficient.
I have been helping teams use Kanban and the Kanban method for a while now and I have used different approaches around WIP limits to identify the one that gives the best results for the teams.
I have come to the conclusion that the most efficient way to go about this is by (I hate the word) imposing the WIP limit at the very beginning of the adoption, as part of Shu in the Shu Ha Ri learning pattern.
The great thing about having a WIP limit is that it gives strong signals to the team
What’s the most important problem we have to solve now?
What’s the highest risk our kanban board is telling us about?
If your board has a WIP limit you will have to answer the questions and act, if you don’t have one, you can always pick the easy cop out of taking a new less important task
The questions posed by the WIP limit are uncomfortable ones, they won’t allow the team to take the easy option. That’s why I believe that teams will benefit from having them since day one.
I have seen WIP limits cause turmoil in teams, people initially feel uneasy. I believe, the feeling derives from the fact that team members don’t believe yet WIP limits will work, and this is due to their aforementioned counter-intuitive nature.
Eventually teams will internalise the fact that WIP limits help the team focus on delivering instead of retreating to more comfortable, less valuable tasks and it does indeed improve flow. But that’s after a while.
My point is, that if we don’t impose the limit at the beginning, the team might not get there on their own.
As I said before I tried many different coaching approaches, the one that worked for me better so far is this
a) A session with the team in which I go into the details of the mathematical reasons why WIP limits improve flow (most people won’t believe everything but will have some context and hopefully some curiosity)
b) Get the team started with a system that includes a WIP limit initially set by me and low enough to be uncomfortable (see above)
c) Attend team’s standups, to discourage breaking WIP and ask the difficult questions I mention above if the team is not able yet to read them from the board
d) Facilitate a retrospective after 2 weeks of use and have a conversation around whether the limit is too low or too high
What was your coaching experience? Can you share alternative paths?
Traditional management approaches have often put high resource utilisation levels at the top of managers agenda as a recipe for effective management, assuming that existing not fully utilised resources are waste. When managers do capacity planning, they focus on utilising all the resources they have to the max, and this approach has often been considered a universal best practice among managers.
For the purpose of this article a resource[1] is a person that works within a team on a product.
Now, let’s have a look at a system where 100% utilisation works well:
Think about an oil pipeline. It would be really wasteful to build a massive pipeline and just push a little quantity of oil through it. Engineers will calculate the optimal pressure and volume of oil that can be moved and the oil will fill the pipe in a constant stream. That’s what I refer to as 100% resource utilisation.
Based on a similar principle, management believe that they should utilise all their resources 100% so that they can push through a stream of value to be delivered to our customers.
So, what’s the problem? You might say. It is easy to agree with that approach but the issue is that by applying the laws of fluid dynamics to people delivering value through software, we underestimate the impact of variability. Human beings introduce levels of complexity and variability that are of an order of magnitude higher to the ones found in an oil pipeline. Oil will flow in a pipe at a steady pace at 100% utilisation, on the other hand a system made of human beings delivering value through software will be affected by countless variables and will not work the same way at 100% resource utilisation.
So, for a better comparison with software development, let’s use a system that is slightly more similar to a software delivery team than an oil pipe is because it includes human variability. Let’s use traffic flow.
Let’s now look at what happens when we try to get 100% utilisation, that in traffic terms means all lanes used with as close to constant as possible flow of vehicles. Human variability factors in this time include for example a driver that gets distracted and doesn’t move when there is space in front of him, or a car that breaks down, or a driver that tries to overtake in between lanes or even a driver that falls asleep at the wheel. The result is something like in the picture to the right.
What’s efficiency for a traffic system? I am simplifying but the throughput of cars would seem to me as a good metric. So let’s say that our measure of efficiency is C/h = number of cars that go through a section of the road in one hour. A traffic jam implies low throughput and high cycle time.
We have all been in a traffic jam and we should know that it is certainly not the most efficient way of using the capacity of the road. When you are in a queue and are not moving, you are not being efficient, you are wasting time and petrol. Starting and stopping is not efficient either as, when breaking, you waste your momentum you gained when accelerating, burning petrol and breaks.
Now look at the picture on the left and tell me, is that more efficient than the traffic jam? Will the C/h of the second picture be higher or lower than the one in the first one?
Believe it or not, the answer is higher.
But, we are not using all our resources! Look at that unused space between cars, surely this can’t be right!
Now look at the two pictures below and see if you can identify similarities with the traffic system.
This is a simple visual representation on how 2 similar systems can obtain higher throughput by limiting the work in progress (cars in transit). It is a counter intuitive idea, but limiting the amount of cars that can be on a road at the same time, can increase throughput. Similarly you can increase your software delivery throughput by limiting work in progress. For the moment I am going to leave it for your imagination to think and speculate whether this is true or not. In the next chapter of this blog post I will use mathematics to demonstrate it. Stay Tuned.
mysoftwarequality 