I recently gave a talk at the BCS London Lean Kanban Day 2015 (http://www.slideshare.net/KanbanDan/coaching-served-2-ways) which was about what I learned as an Agile Coach going through the English Rugby Union (RFU) Coaching Course.

While putting that talk together it occurred to me that while I have a perfectly fine coaching philosophy for my rugby coaching, I didn’t have one that I’d put together for agile and Kanban coaching. I like to think I followed one anyway, but there are benefits to having an explicit philosophy that you have to confront. 

A philosophy helps to maintain clarity, direction and focus in the way you coach and align your behaviours with your values. It can be a anything from a few words, a paragraph or even a picture. Whatever works for you.  A good starting point is to think about the questions: 

“why am I coaching?” 
“why did I get into this in the first place?”

You should also remember that while you yourself are on a journey, so your philosophy should evolve with you. 

Dan’s coaching philosophy
To Learn and Share. No-one knows everything.
To be Open and Transparent.Challenge things, be prepared to be Disruptive.
Coach Situationally  – seek out the Context.
Foster and encourage work to be a Fun and Happy place.
Be Fair and encourage fairness in others.
Be Helpful to everyone.Above all, make a Positive Difference

I posted my philosophy on twitter and linkedin which had some unintended outcomes. I posted it for the same reason I printed it out and put it on my work monitor. I wanted to have to acknowledge it publicly and confront it when things get ‘tricky’.  However I saw a lot of likes, favourites and retweets, as well as a few comments and replies. 

Some people seem to have seen it as a call to arms for all coaches to adhere to my philosophy, while others are troubled by the line about Challenge and Disruption. I felt quite defensive. I’d never wanted others to want to use my philosophy for themselves – that made no sense to me, and I certainly didn’t want people to challenge it, how could they possibly understand my context and why I had decided to value the things I do. This was a personal thing, and all I wanted to do was share it so other people might think “hey that’s a good idea, I’ll write my own personal philosophy down too.”

I don’t mind if you want to use my philosophy in part or in whole, but I do think you might be missing the point if you do.  Let me explain why.

I spent a few days writing down 1 or 2 words at a time on sticky notes about what I value in myself and my mentors. Things I want to do more of. When I hadn’t added any for a few hours, I decided that I probably had enough to be getting on with for now, and anything I missed would probably emerge as I went on. From those words on sticky notes, I created the statements, and threaded them together in a way that made sense to me. I then had a look at the whole and asked myself if that was really what I was about as a coach.

I’d been dissatisfied with myself and my behaviours recently, so I looked to see if the reason might be that I was going counter to my own (previously unspoken) philosophy. It seemed that yes I had. Confronting that in myself has led to me changing some behaviours and I’ve already seen improvements in relationships with some of my colleagues. 

I believe that if I had not gone through the process of creating my own philosophy my own way, I would have missed most of the value. If I had just googled it (like the agile principles, or the scrum values) then I would probably like it, but it wouldn’t be as intrinsically personal to me, and so wouldn’t have mattered as much to me. 

I recommend you give it a go yourself, if you are new to coaching it will help define what you are about. If you are experienced it will help to formulate it in explicit terms and refocus you on why you got into coaching in the first place. 

The outcome is that I’m actually a happier person, and I think I am in a better place to be a better coach. That alone is worth the effort. I’m promising myself some time every year (whether I need it or not) to update my philosophy. My birthday happens to be in April, so perhaps it will be a birthday present to myself.  Perhaps I will run a personal retrospective of the previous year for myself based around what I did and what my philosophy said.  

Technical Debt is a difficult concept for people to understand, and I once came across a wonderful analogy and although I can’t remember who I heard the concept from, I would like to share with you all. I have taken the liberty of embellishing it somewhat. 

Let us imagine we have identified a user need like this:

As a thirsty person in a house,
I want to make a cup of tea with milk
so that I benefit from the unique properties of the oriental infusion and feel sated. 

So you are probably imagining what you need to do: go to the kitchen, fill the kettle and put it on, get the milk out of the fridge, get a mug, a tea bag, a teaspoon and add a sugar to the mug while the kettle is boiling. Add the milk (or if you’re that kind of person, wait until the end to add your milk, it’s up to you, it’s your cup of tea) then add the teabag and boiling water. Wait until a suitable time for you has passed and extract the tea bag, and dispose in of in the bin. Stir to equally distribute the sugar, then sit down and enjoy your tea. What could be simpler?

This is our Value Work - the work done to enable the value of making a cup of tea. 

Hang on, didn’t I mention, you’re not going to your own kitchen, or to the kitchen of the “neatest kitchen in Surrey 2014” award winner. Oh, no.

This is a student house.
Inhabited by students.
Untidy students.
Students who play rugby.

This kitchen is an absolute disgrace and would actually score below 0 in the Food Hygiene Rating scheme. No one has washed up in this kitchen since they moved in at the start of the year. There is nothing remotely edible kept in this kitchen, more that it is a collection area for used takeaway cartons and pizza boxes. 

Now lets think about what you have to do to make your cup of tea. I’m guessing it now involves going to the shop to buy teabags, milk, sugar, a mug, and if you’re unlucky a kettle and some bottled water too. It might involve buying and using a lot of cleaning products before you get anywhere near finding the kettle much less turning it on. 

This is your Failure Demand. This is work you have to do that has nothing to do with the value you are trying to release. This is work you shouldn’t have to do to make a cup of tea. 

This is the technical debt problem. If you tidy up your kitchen (or codebase) as you go, then making tea is a simple thing and most of the effort you spend is in Value Work of making tea. If you don’t tidy as you go, the kitchen builds up in detritus and debris, and eventually even doing the simplest thing involves servicing a lot of Failure Demand - cleaning other rubbish out of the way to enable any value work to flow through the kitchen. 

Whenever you are doing some knowledge work, I invite you to ask yourself, have I left the kitchen in a reasonable state behind me? Is it at the very least no worse than before I started. If not, what would your mum tell you to do about it? Go on, get back in that kitchen, you know what you need to do. 

Imagine a motorway between Starttown and Finishcity. When it all flows it takes exactly 3 hours to get from start to finish for a car, a little longer for a lorry, and a little shorter for a motorcycle, so 3 hours ± 15 minutes. It has 3 lanes in each direction for its entire length. 

Things go well for a time, but demand eventually creeps up due to Finishcity being named the City of Culture, and so we start getting regular tailbacks due to “Sheer weight of traffic.”  All of the traffic now tends to have an extra hour to get there in rush hour. The number of cars per hour arriving at Finishcity at peak rush hour times doesn’t go up, it just seems that rush hour is now two hours long instead of one hour. Pollution and fuel consumption is also up as every vehicle is burning fuel for 4 hours instead of 3. 

Learning 1)

a system of fixed capacity has an optimum flow rate. Pushing more stuff through will not result in an increase in that flow rate, it will just make everything going through that system take longer to get through. 

Learning 2) 

the longer something is in progress, the more cost there is (petrol in cars, effort in knowledge work) to service that same need. 

So how do we solve the problem?

Increase Capacity?

Well we can try to increase capacity, but that will take at least 2 years, mean more demand - all of the work traffic in addition to what we already have, and actually reduce capacity for the 2 years we are working on the roads. 

Shape the Demand?

We can put a toll booth on the front of the road, charging road users to use the road in peak hours (a bit like train tickets being more expensive in commuter times), thus reducing all but essential demand during the peak hours. Or we could use traffic lights on the slip roads to join our motorway, thus causing queues back to the roundabouts at the junctions, and causing drivers to baulk at joining the queue and use a different route instead. 

So we’ve shaped our demand, and that has helped, and journey times are back to 3 hours most of the time. The neighbouring A roads are taking a bit of a hit on traffic increase, but at least the motorway is flowing again. Phew. 

Oh no!

A lorry has jack-knifed, and blocked all 3 lanes northbound! The whole road is stopped! What do we do? 

Well we now have increased demand, we need to get fire engines, ambulances and police to the scene as soon as we can, but how can we do that when there is no way through the traffic? 

Luke, use the hard shoulder!

The what? you mean that our motorway that had all of those traffic problems that could have been solved by having an extra lane, had an extra lane all the time but people weren’t allowed to use it? We are saving 25% of our entire capacity to allow us to have an emergency capability? This is what we really do on our roads. We value the emergency capability so much we throw 25% of our capacity at it. 

Expedite me

In a Kanban system we will sometimes have an Expedite lane. This is like the hard shoulder. No-one can use use it unless they meet some pre defined conditions and rules. They are very expensive, but the cost doesn’t show on the work items that go down the expedite lane, the cost is hidden and paid by every other piece of work that is put on hold while the expedite item is worked on. The same is true on the motorway, the cost of having the 4th lane protected for emergencies is in the traffic that has to queue in the other 3 when the 4th sits idle. 

Hang on a minute...

Don’t some motorways have peak running for hard shoulders now? Yes they do, and this is more like how we do expedite in real life. We don’t keep 1/4 of our team members sitting idle in case something expedite class comes in, they all work on standard work items until they are needed to work on expedite. The cost is then only bourn when an exceptional event happens and the traffic is moved out of that lane to make an on demand emergency capability.

In real life one way to do this is to have a rule where some of (usually your best) people cannot ever pick up a work item of their own, but can pair or swarm on a work item someone else ‘owns’. That way if expedite work comes in, you can move your best people onto that without having to block some other work up, unless they need help of course. It also means that your best people are working with and helping your other people more often, which is a motivator for both sides as one gets to show mastery, and the other gets to increase their mastery (see Dan Pink’s book Drive for more on that). 

I’ve often asked the question, “Why are we doing an agile transformation?” to people in agile transformations, and it’s amazing how people usually focus on the tech teams. Don’t get me wrong, agile is a great thing for tech teams to do, but it’s not where the real benefit is. Lets turn to user stories. I like the format with the {why} at the front as the {why} is the reason we are doing the {what}. 

In order to {why}
as a {role}
I need a {what} 

So what I am really asking them is to fill in the dots:

In order to …
as a participant
I need to transform my technology team to agile methods.

Mostly I get answers about improving the way tech teams work, and I think this is missing the bigger picture. 

Agile isn’t for tech teams. Tech teams become agile to allow the businesses behind them to become agile. I think that is a profound and important thing. The majority of the benefit of having agile tech teams isn’t in the tech team (although there are undoubtedly many benefits there) but is in moving the whole business that it supports from the world of “how are we able to respond to change” to “how do we choose to respond to change”. 

If the tech teams are not agile, when change happens in the market, or a product is not received as expected, the business has to quickly ask what they are able to do to respond to the situation. "What options are in the land of the possible for the business now that we are in this new scenario?” 

If the tech teams are agile, the question isn’t about "what we are able to do", but rather, "what do we choose to do?" We can quickly change our focus from our current work to something else. We have cross functional feature teams all ready up and running, so we can choose to re-prioritise some new work with very little impact and very little lead time. 

That might sound minor, but in fact it is the biggest difference tech teams can make for their businesses. Imagine a meeting where a senior stakeholder comes along and tells the story of a business critical event in the market - like Apple and Google choosing to join the Mobile Phone market for example, and asking the tech teams what they are able to do about it.

Imagine standing there like a builder sucking air through your teeth when being asked if a wall can be moved in your house. "We have to finish the big projects we’re working on or 16 months of work will be wasted,” you hear yourself say, "and the codebase will be completely unstable as we haven’t done our testing phase. We should be able to start work on the new big thing next quarter, as long as things go well.” Ouch. 

Imagine instead saying, “Okay, no problem what would you like us to do? We can start work today on the big new thing, lets cancel x,y, and z and get the teams together for a workshop in half an hour." 

Yes our tech teams benefit from agile practices and principles, but the point of it all is really to enable our business to be agile. That is the real advantage we are buying with an agile transformation. 

In order to enable Real Business Agility
as a CEO
I need to transform my technology teams to being agile.

I’ve been struggling for a metaphor to help explain the difference between statistical forecasting and estimation, and this one came to me, so lets give it a whirl. 

Let me express the scenario in some human readable BDD (Gherkin) language

Given I am an orange juice shop owner
and currently have no oranges
when I buy 25 boxes of oranges of varying sizes and varieties
then I need to forecast how many glasses of juice I can produce to sell

Let me now describe two different approaches, the first like normal agile estimation processes, the second like a scientist. 

Method 1 - Estimation

I close my shop to customers gather my team together. I open the first box of oranges and hold up the first orange, showing them how plump it is and telling them it looks like it is probably a Belladonna variety orange (http://en.wikipedia.org/wiki/Orange_(fruit)#Common_oranges).

I ask them all to estimate how much juice the orange will yield. They each choose a planning poker card and I count them down, and they reveal their numbers. I ask them to discuss any outlying responses and then re-estimate until we get consensus. I note the number and move on to the next orange.

The second orange is a Berna orange and is quite small.  We estimate that one. And so the long day goes on, with us repeating the process and selling no orange juice. 

Eventually we finish estimating the first box, and we have a number which is our estimate of how much juice box 1 will yield. We have to make a decision, do we stop estimating and open the shop to sell some juice or do we go on and do the same process on box 2 through box 25. 

Some juice shops stop at 1 box and use the estimated yield for that box as the "magic number" of yield per box. Other shops keep on going until all 25 boxes have been estimated one orange at a time, because they need a “more accurate estimate”.  The downside of the accuracy is that we had to buy it by keeping the shop closed for 25 times as long. 

What do I get at the end? Somewhere between 200 and 300 Story Points of oranges. 

Method 2 - Mathematics & Science

I open box 1, and count how many oranges are inside. I also open boxes 2, 3, 4, and 5 and count the oranges in each of them. 10 minutes later I open the shop for business and start my staff selling juice. 

When a customer orders juice we measure how much juice the first 11 oranges actually yield. We don’t estimate, we measure. 

I now have enough data to make a pretty accurate forecast of how much juice the boxes will yield. It’s only taken me 10 minutes. 

Now for the sciencey bit. The German Tank Problem (http://en.wikipedia.org/wiki/German_tank_problem) is a famous bit of Bletchley Park Boffinery from the second world war. To save you a bit of reading, the Allies wanted to know how many of a particular tank they were likely to come up against in France when they invaded. There were 2 ways of getting the forecast, via Military Intelligence estimates, or using Statistic and probability. Lives depended on this so it had to be correct. 

Here is a comparison of the 2 methods used over time, and on the right, the actual numbers found out at the end of the war. 

So the provenance for using this method is pretty good. Lets apply it to the oranges. 

The key to it is understanding that the maths lets us make very accurate predictions using very small sample size. Indeed the formula below shows how likely the next item measured falls within our existing range of highest to lowest values, where k is the size of our sample 

% Likelihood  = (1 - (1 / k – 1)) * 100

So if we have 5 boxes of oranges  with 17, 23, 16, 30, 25 oranges in each, the likelihood of the 6th box having more than 16 oranges and less than 30 is (1 - (1 / 5 -1)) * 100 which is 75%. 75% likelihood of all future boxes being inside the current know range from a sample of only 5 boxes.

A sample of 11 gives us 90% likelihood of the next being within our known range. Credit goes to Troy Magennis for explaining this to me over a couple of Weissbiers at the Kanban Leadership Retreat in 2013. 

So thats a likelihood of 75% that we have between 16 and 30 oranges per box. That gives us a median of 23 oranges per box

So, how much juice will we get per orange? For the 11 oranges I measured I got  79.1, 78.5, 71.2, 72.1, 65.2, 79.3, 73.2, 67.2, 65.0, 75.3, and 69.1 ml.  

So thats 90% likelihood that all oranges have between 65.0 and 79.3 ml each. That gives us a median of 72.2ml juice per orange

So I have 25 boxes, each with 23 oranges, each giving 72.2ml juice. I have a total yield of 25*23*72.2 ml of juice = 41.515 Litres of Juice. I’m going to have to buy a lot more boxes to keep my shop in stock for the day. I’m glad I found that out early enough to get back to the wholesalers in time. 

In the knowledge work world, we tend to have to solve the same problem for forecasting work completion, and measure days per work item, and work items per “epic” or “MMF” or “MVP” or Project (whatever you call your orange boxes in your context). If you want real accuracy instead of working out medians and using those, you would plug the very same numbers into a Monte Carlo Simulation of your system of work, and work out how many of the project runs finish before each date. That is much more complicated to do, and requires a good old dose of processor power, but is far more accurate than my simple sums on the median values. However, even my simple sums are much more accurate than estimation, and cost much less time off from doing value work to generate. 

If you’re running an IT Software project with 25 epics, you’d break down the first 5 epics into stories (the ones epics you’re going to work on first anyway) to work out the stories per epic number. When you start work you can see that each story takes between say 2 and 9 days based on a sample of 11 stories… We have all the data we need to make a good forecast, and not one piece of estimation has occurred. Most of the data is derived from doing the actual work we need to do to finish the project. Which is ideal, as it means we are focusing on doing the thing that will get us finished, and the forecast is a secondary outcome, not a distraction from doing the work like with estimation. 

Numbers Game

Whenever I’m in a meeting talking about metrics, someone always brings up Velocity. If you’re familiar with Scrum you’ll know that in this context, velocity means the number of story points completed per sprint. If a team completes 4 stories each of which scores 5 story points in one sprint, the velocity of that team is said to be 20.  If that doesn’t make sense, you should probably do some googling about now and come back when it does… don’t worry, I’m happy to wait for you. Look up planning poker while you’re on.

Ok ready to continue? 

Velocity isn’t a metric

No, Velocity can never be a real metric, and to use it as such is to play a dangerous game. But let me explain why this is so, and if I’m taking it away, what you can replace it with (or use alongside) as a real metric. 

Numbers are Magic

It is my belief - although as yet I do not have any scientific data to back myself up - that numbers hold a special place in our minds. Numbers and Mathematics are after all an abstract construct developed by humans as a language to explain science. It is my premise and belief that we see things that are expressed as numbers as things that we can control. If my mass is 125 Kilograms, I can target loosing 5 kilograms then go on a diet and exercise regime, and measure my progress with my measured mass on any day. 

When is a number not a number?

What madness is this? Well I’m trying to show the difference between a real mathematical number like say 3.142 and a string of digits like 055555 555 555. You probably recognise both of those, one is a shortened for of Pi, which we use in trigonometry to work out areas and circumferences of circles, and the other is a fake uk phone number. However doing maths makes sense with Pi, it doesn’t with a phone number. Imagine adding 44 to them.

x= 44+ 3.142, so x= 47.142

y= 44 + 05555555555  ….

While you can work out that y = 5555555599, it really makes no sense, what we really want to do is manipulate the string of digits to be  +445555 555 555 - the international form of the phone number. 

So some numbers are real mathematical numbers and others like phone numbers are just strings of digits, so we need to very careful whenever we use something that looks like a number but is really a string of digits as people will most likely not understand the difference without explanation and try to use the number as a real mathematical number and a control point. 

Velocity is a tricky one as it looks like it should be a real number, after all we can “Measure" it for a team. But appearances can be deceptive. My old Physics teacher at secondary school once told me that “if the maths is ever confusing, look at the units and they will help you understand what is going on.” Wise words for maths, physics and velocity. Velocity is measured in “story points completed per sprint” which might as well be “tulips completeted per sprint”  The problem with that is that it is a malleable number. 

Malleable Numbers?

What do I mean by a malleable number? Malleable means “easily influenced; pliable”. So let’s pretend I’m a Command and Control manager who is up against it for a project. I see Team A with a velocity of 22, and Team B with a velocity of 35. If I think these are real numbers and in my mind they are therefore control points, so I would be likely to ask the question, "how come Team B is so much better than Team A, and why can’t Team A do 35 points per sprint too?”

We, as the kind of people who read blogs like this, probably know innately that that question is a danger sign, but lets follow it through.

Team A get pushed into working towards a target velocity of 35 points. So what are they likely to do in the next story grooming (refinement) meeting when they come to estimate their stories? I suggest that a story that would have been a 5 last time round will now be an 8 - or even a 13 point story. Why am I so confident? I’ve seen it happen in my own teams. But that is the least of the problems.

As a free gift with the instruction from manager to team there is a side order of “understanding that Management don’t seem to have a clue” which undermines the organisation, and pushes the team towards being more insular and deceitful.

It has a negative effect for everyone. Even if the team doesn’t “cheat” on estimation, they may well start “sand bagging” the sprint by working longer or extra hours. And of course that will artificially uplift velocity at first, but as people get tired, the velocity will actually drop (again I’ve seen that in action) as people stop working in a sustainable manner. 

As soon as the thing we are trying to control is malleable, as human animals we can’t resist playing with it. A bit like a blob of blu-tac on your desk, it’s malleable and you can’t help but play with it. How do we solve that problem? We put the blu-tac away in a packet, drawer or cupboard. We need to keep the malleable stuff away from the people who want to play with it - so it is with velocity. Just like blu-tac, velocity is a useful tool when used correctly (like for deciding when to stop grooming stories at the story grooming meeting), but should be put out of reach the rest of the time. Use something which isn’t malleable as your metric - like how many days stories take to deliver. In the Kanban world we call that the Lead Time, and it is measured in days (or sometimes hours), a fixed unit of time. Unless we solve the problem of light speed travel, fixed units of time are Immutable Numbers.

Scrum and Kanban, What’s the difference?

My intention was a short blog, but it quickly grew into a long one to explain what I meant. With that in mind, the conclusion is at the top, please read that first, then decide if you want to go on to read the “working out” in the Body. 

Conclusion

Short version

• Both Scrum and Kanban are good things but are very different beasts.
• Kanban is a way of getting better at doing what you do.
• Scrum is a way of being agile in software delivery. 

Longer version

• Scrum is more than just a framework, its essence is really its Values and Ethos: Inspect and Adapt. 
• The Scrum Framework is really just a “starter for 10” to get you started in agile development.
• Many people think the Scrum Framework = Scrum, but this is incorrect. 
• Kanban is not a methodology or framework. It is a way of evolving and continuously improving your framework. 
• Kanban doesn’t have a suggested framework, it challenges you to start with what you do now and improve.
• Comparing the Scrum Framework and Kanban is like comparing apples with fruit. 
• It’s still a useful comparison if only so that we can explain the difference, and why you can use Kanban to improve on pretty much any way of working.
• When you’re trying to evolve and improve, everything is up for grabs.  
• Evolving from a pure Scrum Framework to a Kanban implementation is easy, and you can still call it Scrum

Body

Still with me - thanks. Lets get into it. 

As an Agile Coach / Trainer and Kanban Coach / Trainer I’m often asked what the difference is between Scrum and Kanban as if we are comparing two different Methodologies. This is a much more difficult question as we have to address some misconceptions before we can answer in a meaningful way. 

What is Scrum anyway?

Scrum is NOT a framework for software delivery. (If you think this is contentious, bear with me a little). 

The Scrum Framework IS a software delivery framework, but while that sounds like splitting hairs, it really isn’t and if you are stuck in the “Scrum is the framework and that is all Scrum is” way of thinking you are imposing a false limitation on the way you are working.

Scrum > Scrum Framework 

So I ask again, what is Scrum? 

Scrum is an agile way of working which includes Values, an Ethos and a Framework for software delivery. The framework is the easy bit to learn, teach, test, and write about, so it is the part of Scrum that tends to get the focus. It is also the lightest weight part of Scrum once you get into the other areas. 

Agile at it’s roots is really a set of 12 principles listed here http://agilemanifesto.org/principles.html The Scrum Values: Focus; Commitment; Openness; Respect; and Courage, are really focused on addressing the 12 principles of agile. They tell us what Scrum is really about, it’s about working together effectively and transparently as a team, being brave in our approach to our work and way of working. 

The ethos of Scrum as I see it is really: 'Inspect and Adapt’; and be Agile.

So what about the Scrum Framework? 

The Framework is the easy bit. Here’s a set of rules: roles; practices; and meetings. If you follow this set of rules, things should improve and you will find you are starting to become more agile*.

One Sprint into Scrum, you should have your first retrospective and start getting down to the Inspection and Adapting.  Here comes the problem. If you are committed to the Scrum Framework as being sacrosanct, then you are limited in what you can adapt. We have surely all heard of ScrumBut as a concept (we do Scrum, but we don’t do xxx) which is presented as an anti-pattern. To most of us this really means we do the "Scrum Framework, but we don’t do xxx”. But how can we truly be agile and commit to inspect and adapt if you choose to constrain ourselves to never changing large parts of how we do our work? I think Scrumbut as a concept does more harm than good.

In that situation you either have to live with Cognitive Dissonance or you have to accept that the framework is just a "starter for 10” to get you started while you get to understand the values and ethos, and start becoming more agile. 

That’s how I treat the Scrum Framework. It’s a good place to start, but since your particular context was never considered in the creation of the Scrum Framework, it may have worked perfectly “there and then” it cannot be perfect “here and now” in this different context. If you are developing software, then there is a good chance it will be good enough to be a lot better than a non-agile way of working, which is why it makes a good starting point for new dev teams just being formed for the first time, or for people who choose to make the revolutionary change from waterfall to agile**.  

I am sure that the creators of Scrum never intended any part of it to hold you back from improved agility or higher performance. If you find that something inside the Scrum Framework is holding you back, you have the right and the responsibility to inspect and adapt. I would argue that evolving your framework from the ‘vanilla’ Scrum Framework is more Scrum than sticking to the Scrum Framework rules dogmatically.

What is Kanban 

If you already know the answer to that question, keep reading, more than 90% people I’ve met who 'know this already' tend to get it wrong.

Kanban is a descriptive method for evolutionary change based on the use of simulated kanban systems. 

Yes Dan, but what does that actually mean? 

The first thing it means is that Kanban is not a methodology or a framework. That is important.

Comparing Kanban to the Scrum Framework is unlike comparing apples with apples or even apples to oranges, instead it is more like comparing apples to fruit. That is why it is such a hard question to answer.

“What's the difference between a Ford Fiesta and Volkswagen Golf" is easy. "What’s the difference between a Ford Fiesta and a vehicle” is harder to answer because you have to interpret the question and change it before you are able to answer. 

Kanban doesn’t tell you how to do software delivery (or any other knowledge work). It tells you how to get better at software delivery (knowledge work). Every implementation of Kanban can (and should) be different. Some can even look a lot like Scrum on the surface. Others look nothing like Scrum. The key point is that Kanban allows teams to continue making small improvements and changing to what is needed as the context they work in changes. 

The foundational principles of Kanban are: start with what you do now; agree to pursue evolutionary change; initially, respect current roles, responsibilities & job titles. That means Kanban is applied over your current way of working, and you then start making improvements. There is no target perfect framework, only the concept of getting better at what you need to do. If you do Scrum today, when you start your Kanban journey, you do scrum tomorrow, but then you change your process to what you need it to be, no matter what a book says. At some point soon you will realise you no longer conform to the Scrum Framework. That is fine for both Kanban and Scrum. 

Evolving from the ‘Starter for 10’ Scrum Framework

It doesn’t take a lot of mental work to allow that a Scrum Framework is close enough to call an implementation of Kanban. Good Scrum conforms to the core practices of Kanban. Once a good Scrum team has got going (at some time after an agile transformation) it conforms to the foundation principles of Kanban. The only thing you have to do is release yourself from the shackles of ‘sacred rules', allow yourself to improve by collaborative experimentation, and implement a reasonable measure of productivity*** so that you can validate your learning and demonstrate your improvements. Everything is up for grabs

Look at your rules, work out if any of them are holding you back, actively decide to break (change) the first rule that is slowing you down, and measure if it made things better or not. Move onto the second rule change. Keep on doing that. Feedback -> change -> measure -> feedback…. This is Inspect and Adapt, or Probe, sense, respond, or plan, do, check, act, or even scientific method.   

The dirty little secret

You don’t even have to call it Kanban, if you prefer you can still call it Scrum, if you mean Scrum in the wider sense than just the Scrum Framework.  

Want to learn more?

book yourself up for our Kickstart Kanban class here

Footnotes

* I’m a firm believer that agile is something you are (or become) rather than something you do. 

** which is a risky business in itself and usually takes longer to show benefit than organisations predict. Hitting the road running with benefit is hard and rare. 

*** try Lead Time: the real elapsed time between Committing to finish a Work Item and finishing that work item; and Delivery Rate: How many Work Items you finish per day. 

How a humble bottle of tomato ketchup can teach us about flow, pull and push. 

Knowledge work tends to be Complex Adaptive work. That means as you try to solve a problem, the solution leads to a change in the problem you are trying to solve. It’s a bit quantum to be honest. You can either know what problem you’re trying to solve, or where you are in solving the problem, but you can’t know both until you’ve finished. 

What that means is Emergence happens. Emergence means that new work magically appears as you try to solve your complex adaptive work, so there is always (or close enough to always) more work to do than you think there is going to be. So if you plan 8 hours of work, you actually need 9 or 10 (or more) hours to finish it. So if you plan 100% utilisation based on the 8 hours, you are always going to be over capacity and needing to do say 2 hours extra per day to keep up. I suddenly have the U2 song “Running to stand still” playing in my head.  Time to start the metaphor, here we go.  

Lets imagine I have a plate of chips in front of me. I fancy a bit of tomato ketchup with my chips, but oh no! It’s the dreaded traditional glass ketchup bottle. 

I think we have all trained ourselves to solve this problem. Once upon a time when we were younger, more headstrong and foolhardy we would tip the bottle right up to 180º and, oh dear the ketchup has used the whole bottleneck, no ketchup can flow! Disaster!

What should I have done? Well the older, wiser, more thoughtful @KanbanDan knows that you have to tip the bottle to the optimum flow angle, whereby the ketchup almost, but not quite fills up the bottleneck. In order for flow to happen, the bottleneck cannot be 100% utilised.  

But what if I tip it too far? Well the adage about Push, Pull and Flow might just have the answer. 

Flow if you can, pull if you must.

(you may have noticed the absence of the word “push” in there, this is a deliberate omission)

You now have 2 options if you want ketchup for your chips while they are still hot:

1) The Push approach. 

You can start smacking the bottle on its bottom repeatedly until ketchup splatters out of the bottle. This tends to have consequences, which are exaggerated if you happen to be wearing white clothes or have a white table cloth.1

2) The Pull approach

Find yourself a knife which is narrower than the bottleneck, stick it in the bottle and pull some ketchup out onto your plate. If you pull effectively while maintaining the correct flow angle for the amount of ketchup remaining in the bottle, this will encourage flow to start. Flow if you can, pull if you must. 

Kanban is not a pull based system by design. Kanban is a flow based system, which suggests the use of pull where flow isn’t naturally occurring, to encourage flow through the bottlenecks in your system. 

Just like the ketchup bottle, if you plan to use your bottlenecked or constrained people or resource at 100% capacity, emergence will bite you and cause flow to fail. If that happens, sort out the flow angle (replan at less than 100% utilisation) and use Pull to get you out of the hole you just got yourself into. Pushing will just make things get really messy really quickly. 

"But why not just use a squeezy bottle Dan” I hear you ask?  

Well next time you get over capacity in your system, ask your most constrained person to stand up, wrap your arms around them, squeeze them hard and see how fast you end up being called into HR for a meeting. Just deserts for people who stretch metaphors too far  

 Merry Christmas Kanbanistas! 

I recently blogged here on Is Estimation Waste and I would like to come back to it. There is a movement in Lean and Agile towards #NoEstimates which has a lot of  value, but I still believe that we are risking missing something if we don't find an alternative method to get the value we get from Estimation (shared tacit knowledge just before we start work on the Work Item) when we throw away our Estimates.

So with that warning all done, how do we go about throwing away estimates? To start simply, we need to size our Work Items instead. This is something we all already impicitly do before we bring 'stories' or Work Items in to be estimated, but now we just need to be a bit more granular with it.  Let me use a metaphor.

A dry stone wall is an ancient British technique for building walls using stones with no adhesive cement, hence 'dry' stone wall. This skill has allowed what is essentially a cleverly constructed wall which is a pile of stones to stand solid for hundreds of years in some of Britain's most exposed and weather beaten areas. 

As you can see in the photo to the right, each stone in the wall is a different size and shape, every stone is unique. However while some stones are small and some are large, none of them are Boulders, and none of them are pebbles. Each stone is small enough to be lifted into place by a single person.  

Interestingly there is a rule in dry stone walling, you don't go looking for a stone to fit a place, you pick up the next stone and do not put it down again, you find a place to use it. 

The point I am making is that you cannot use Boulders in the wall, they are too big and unwieldily, so boulders have to be broken down into stones, and once a stone is stone sized, it gets used as soon as it comes to the top of the pile.  It would be hard and also pointless to estimate how big each stone is, they are all irregular shapes with sloping sides and pointy bits. 

This is the same thing as sizing your Work Items. Like a stone, every Work Item is unique, with differing size, complexity and emergence (all work items are likely to have some differing level of emergence in a Complex Adaptive environment). It takes much less effort to look at a proposed work item and decide if it is a 'stone',  a 'boulder', or even a 'mountain'. If it's bigger than a 'stone' get out your hammer and cold chisel and start breaking it down into stones. Judging if a Work Item is 'stone' sized takes very little effort for a very small number of people, much less effort than estimation.

So by sizing them using maths with only 11 previously completed work items I can give 95% likelihood that any new work item will be smaller than our current largest. Contrast that with using Estimation instead. Once you have 11 work items finished each of them stone sized, you know the 12th work item is likely (this is the mathematical version of the work likely) to be smaller than your largest completed work item and larger than your smallest completed work item with a probability of 90% without even knowing anything about that new work item other than it has been sized to be a 'stone'. This is statistics working from us, and with more data points the accuracy of the prediction increases. It is also worth noting that of the 10% tolerance with 11 data points, 5% of that is the likelihood of the new work item being larger than your current largest work item, and 5% is the likelihood that it is smaller than the current smallest. Most of us aren't going to worry to much if it comes in smaller, so you have 95% likelihood that the new work item is smaller than your current largest. 

Remember we work in a Complex Adaptive scenario with continually changing context, and each Work Item requirement is also Complex and Adaptive, so we have multiple levels of emergence in the work we do. So no matter how good we think we are at estimating (and if you don't measure back on completion you don't know how good you are, and that is even more Failure Demand to work it out) we are at best going to come out with roughly 60% accurate estimates. That number comes from empirical study. 

So with simple (quick) sizing with low amounts of waste we get accuracy above 90% as soon as we have completed 11 work items (and most teams have already completed many more than 11). With Estimation which usually happens after sizing has already happened - we often call sizing grooming or story refinement in that scenario - we only get 60% accuracy. I'm not here to tell you that you're doing it wrong, but if you are spending more effort to get 30% less accuracy in your predictions, you might want to have a think about why you are doing the estimate in the first place. 

Remember,  if you are going to stop estimation, you need to find a way to replace the real value in estimation - the shared tacit knowledge. Even if that means you keep on estimating only to get that benefit, it seems like a useful thing to me. However, if you do keep on estimating, please do yourself a favour and throw away the estimate at the end, it's doing you no favours. Do the maths instead. It's faster and easier, and gives much more predictability that your stakeholders will love, and will make your job much less stressful. 

When I go into organisations adopting Kanban or advanced Agle, they often know that they should be limiting WIP (Work in Progress) or even are limiting WIP without really understanding why. I'm hoping to make that a bit clearer in this post. The main point of limiting WIP is that it reduces the average time taken to finish each Work Item - the Average Lead Time as I define it. 

But why does Lead Time reduction matter. Well I think you might know that intuitively if not explicitly, but here it is - 

The shorter the Lead Time is for a Work Item, the less EFFORT is needed to finish that Work Item.

That is pretty profound, and indeed may even be controversial but it is absolutely true. If you do the same work in a way that has high WIP and longer Lead Time, versus low WIP and short Lead Time, then it will take more effort. 

Let me demonstrate at Kaizen Street

At KanbanDan's Garden Service. I have a contracts to maintain the lawns for the 12 almost identical houses in Kaizen Street, and for each my workers have to: 

• Weed the lawn
• Mow the lawn
• Strim the lawn edge

• Bob is an ace mower, he can also strim to an average level, but is slow at weeding
• Ian is an expert strummer, average weeder, but slower than average at mowing
• Flo is the best weeder, average at mowing and slow strimmer.

I have 3 mowers,  3 strimmers and 3 sets of weeding gloves and tools. Each lawn on the street is identical, so I know they take 60 minutes for one average person to weed, 30 minutes for one average person to strim, and 60 minutes for an average person to mow. 

It takes 15 minutes to move the equipment from 1 location to another and set it up / store it on the van. At the start of the day and after lunch the first thing to do is unpack the gear. Last thing before lunch and at the end of the day, the gear must be packed onto the van for safety. It also takes 15 minutes to move the workers gear from one house to the next. 

Lets assume that the most gardens I'm ever going to work on at once is less than or equal to the number of workers, so it's going to be 3 maximum. That may sound familiar as that is how many IT teams start limiting WIP, 1 work item per team member maximum.  

So I have 2 options open to me. I could set each worker to work on a garden each, - the Maximised WIP solution, or I could have them swarm on 1 garden together - the Minimum WIP solution. 

Lets consider the Max WIP "1 Garden per Worker" solution first:

On Monday morning at 9:15AM, Bob goes to number 1 Kaizen street, Ian takes number 2, and Flo takes number 3, they unload their gear and all start weeding, then when their weeding is done, they Strim, then they Mow the lawn. 

At Lunch on day 1, my team of crack gardeners have finished 1 Garden but are well under way on 2 more, and have earned me £20

 

At the end of day 1, they have finished 4 gardens, and earned me £80 

 

At lunch on day 2, they have finished 7 gardens and earned me £140, but have worked on 2 other gardens

 

At the end of day 2, they have finished 10 gardens and earned me £200, and wasted effort on 11 and 12 as they never got finished so never earned me any money. 

Now for the Minimal WIP solution for the same problem

At lunch on day 2, they have finished 9 gardens and earned me £180

At the end of day 2, they have finished all 12 gardens and earned me all of the available £240. Kaizen street has happy homeowners, and I have happy employees. 

My answer would be "Yes, but…"

I've always said:

"Estimation is valuable, estimates are waste"

So if you can get the value that you would get from estimation in another way that provides a valuable output as well, then estimation is waste. 

However a recent chat with Colin got me thinking about how I present that thought, as it has a subtle nuance that makes all the difference. 

Let me break it down, starting at the back end. "Estimates are waste"

In IT we tend to work on Complex Adaptive requirements, so trying to pin down how big work really is before we start it is next to impossible. The estimate itself doesn't actually deliver any value to us, it's the work item itself that delivers the value, so, the time we spend estimating is time we could have been spending working on the work item, and allowing the emergence to occur. In other words we are wasting effort producing something that doesn't actually deliver any value and reducing the time we have available to do the work itself. 

But, "Estimation is valuable"...

I said it (on the internet no less) so it must be true. When a team spends time estimating, we are taking parcels of knowledge which is locked away in the heads of individuals (usually more than one) and sharing it amongst the entire team. We are turning tacit knowledge into explicit and shared knowledge.That is a very powerful and valuable thing to do, as it means we are working with our eyes open rather than working blind to knowledge we already have partitioned away within the brains of individuals. 

So if we are in a Kanban team and stop estimating, how do we still get this hidden value of estimation? Well we can use something like BDD (Behaviour Driven Development) to have the same discussions, and bring out the tacit knowledge. 

So that's all sorted then, so why the Blog post Dan? 

If a team starts out as a Scrum team, then it will do estimation as part of grooming and planning. We learn about drawing out tacit knowledge and making it shared and explicit. We intrinsically start to understand the value we get from it. We can then evolve into getting the same knowledge and value from other activities such as BDD, and therefore stop estimating all together, recouping the waste and replacing it with something of value (Gerkin tests). 

If we don't go through that learning, but jump straight to not estimating, we haven't learned about the value we are missing. We may well not know we are missing it (although we are likely to be very frustrated by work seeming to have very high levels of  emergent work). 

There is a reason we advocate evolutionary change rather than revolutionary change in Kanban, so we should Limit the Change in Progress to an acceptable level for the team in question, and we should only abandon estimation at the point when the team knows the value it gets from it, and has an effective way of replacing that method of gathering that value. 

in Conclusion...

Estimate on, until you know what you're missing, then find a way of getting that same value from something else before you stop estimating. 

I've often heard Agilists referred to as Evangelists, and it's always rankled with me. Lately I've been wondering why that is, and this is what I came up with. 

It's hard to talk about Evangelism without touching on religion, which is often an emotive subject. Nothing in this post is intended to offend anyone's beliefs of any kind, but rather based on bare facts as recorded in history. If I have managed to offend you, I apologise, it was not my intent.

Lets study evangelism. I've looked it up from several sources and what I understand it to mean is:

Evangelism: the act of spreading the word about a religion (usually but not always Christianity) with a view to converting people from other religions. 

So in other words, Agile Evangelists are seen as people who are trying to move other people from their old beliefs into the 'new' religion of 'Agile'.

Why would I object to that? Let me count the ways:

1) Religions by definition are based on faith in a set of beliefs which cannot be otherwise proven scientifically or empirically. Agile is a set of practices and patterns which have an empirical basis. We can prove our beliefs using scientific method to show they do work, and how they work.  For example, if we are talking about the agile practice of 'Limiting WIP' I can use games to show you how it works, then show you the maths to prove why it works. 

2) Evangelism is a religious word implying we are somehow religious fanatics challenging people's existing beliefs. I've never yet seen someone fight to convert people to agile. If we try, then in effect all we manage to do is to polarise the beliefs  of the person we are trying to convoke, and make it harder for them to understand.

3) We are coming in straight at the belief barrier. I would suggest you go read / listen / tweet / converse with Benjamin Mitchell about 'double loop learning' and 'the ladder of inference'. Even if you don't, it's simple for us all to understand that if we say "The thing you believe in is wrong, this however, is the right belief" that you are going to have a lot of work on your hands to convert someone. 

4) We are assuming that Agile is the only game in town that works. That is clearly wrong or the IT business would have died a long time ago. Waterfall can work. Agile can fail. I would suggest that if you look into it, the projects with the best implementation of the chosen Methodology or framework are the ones most likely to succeed, and the ones with poor implementations are the ones most likely to fail.That said, emergence and dumb luck are also factors.

I would say that having run projects both ways, a good agile implementation is better suited to emergence than a waterfall one, and therefore less likely to fail, but I honestly believe that a good waterfall implementation has less chance of failure than a bad agile implementation. I don't have the data to back that statement up and it would take a piece of work to long for me to undertake to go through enough suitable case studies to back that up.

I also think it's important we talk in terms of failure rather than success in that statement, just because something succeeds, it doesn't mean that thing was less likely to fail along the way. Just occasionally a lower league team wins the FA Cup. It's far more likely that one of the big premiership teams would win, but just occasionally it happens anyway. 

What's the alternative to Evangelism? 

As an astronomer I am led to think of Galileo Galilei. He was the guy who made the case for Heliocentrism, which isn't quite as catchy as Agile as a title, but  is the astronomical model with the Sun at the centre of the solar system, and was far more contentious at the time. We know this to be true today, and we'd probably mock people who believed in the old models like Ptolemaic system where the planets and sun orbited the earth.

Galileo didn't come up with the idea for Heliocentrism, far from it, it was proposed thousands of years earlier, but no-one could prove it one way or another. Even a hundred years before Galileo, Copernicus presented a heliocentric system, but again couldn't prove it.

Galileo got the data. Galileo improved telescope design and was able to observe the moons of Jupiter and Saturn, and crucially record their phases. To this day, the four largest moons of jupiter are referred to as the Galilean moons, and can be seen with a standard pair of 10x50 binoculars on a clear night.

Why does this matter? He used scientific method. Tycho, Copernicus et al were correct in their hypothesis, but couldn't devise an experiment that could be run at the time to prove or disprove the hypothesis.

Scientific method is to: a) have a hypothesis or idea; b) devise a set of experiments to test the hypothesis; c) run the experiments and gather empirical data to show the validity of the hypothesis; d) accept the results which ever way they go. 

Galileo had the equipment to prove the Ptolemaic model was wrong, and that heliocentric models were correct, so he ran them and published his results. 

Hang on a minute wasn't Galileo vilified? 

Yes he was. He had the facts that showed the truth in what he said, BUT he was going head on with the core beliefs of the current Pope. The inquisition was sent round, and he was instructed to recant or be excommunicated. He was subject to a papal decree that he was not to teach Heliocentrism again. 

He took on the accepted general beliefs with real data, and still didn't win. In modern parlance, he built it, but they did NOT come. We need to learn from this too. Proof is not enough!  In a recent engagement the CIO told me, "Don't tell me about Pairing. I've seen all the 'proofs' and the 'data', I just don't believe it's more efficient to waste time having 2 guys doing one guy's job." Proof didn't counter his beliefs, and he told me that all agilists are evangelists! Thinking back, that is probably the origin of this blog post… 

What should we do instead. 

Get the data, and talk from a position where we are dealing in scientifically proven facts. It's really important that you don't only believe what you are saying, but that you can prove it. Even then, it takes more than proof is not enough. People put a lot of time and effort into their beliefs, and often don't want to hear that they might be wrong. 

Remember who you are talking to, and ask yourself how they got there. If you're talking to a senior programme manager or higher, the chances are they were a good project manager in the past using PMP, Prince or something similar, and ran successful projects. They already know what works, they did it to get where they are. Telling them waterfall doesn't work is not only factually wrong, it is something they intrinsically know to be wrong because it was what they did themselves. You just threw away all of your credibility. Do not pass go, do not collect £200. 

How do we convince them? We talk about common outcomes. Work with them about trying to get to a common place where we can do things better. Don't take them on head on, even with the truth on your side. Being right didn't help Galileo much at the time, did it? I've never heard about a project that didn't want early and frequent delivery, the ability to change quickly as needs change without wasting project money on the things you will never build. They are talking to you because they know something is up, so help them understand how things can be better and have more chance of success. 

Always make it clear when we are talking about our beliefs rather than something we can prove. We need to be honest and open if we want to gain trust. And if you can't prove it, ask yourself why you can't, and either get the data to back yourself up, or consider stopping saying it.  Remember what I said about a good waterfall implementation being less likely to fail than a bad agile one… well I never said this stuff was easy did I?

Come on people let's stop evangelising and start educating!

A common thing I hear in new agile adoptions is the concept of making the team Cross Functional. That is, the team should have all of the skills necessary to complete the work being undertaken. 

However, what I then often see is a desire to make the individuals within the team cross functional, rather than the team. In effect, the organisation seems to be looking for a team made up of Cross Functional People. I think that this is just plain wrong. Let me tell you why...

Lets pretend we have a team made up of 3 disciplines. QA, Dev and DBE (database engineers). A bit like this

I've intentionally intersected the skill sets in this Venn Diagram as this how people are, we like to pigeon hole them into one thing, but in reality we know  a lot about our area of expertise plus a bit about other areas. Assuming you only need these three skillets to deliver your work, the above Venn Diagram represents a cross functional team. 

The problem I am blogging about is the tendency to try to move people from each specialism, into the middle of the diagram where all 3 skill-sets are intersecting.

But why not?

If you are unaware of the work of Dan Pink, may I take this opportunity to point you in his direction - watch this 10 minute video 

If you watched it, you will now understand a little about Motivation - and the key drivers of Autonomy, Purpose and Mastery. 

How do you think it will affect the motivation of a DBE Expert to be told that their expertise is no longer valued and instead we want them to become a cross functional generalist who is just as good at all things? Ever heard the phrase "Jack of all trades, master of none"? You are effectively destroying their Mastery driver. Hands up if you want to actively sabotage your team members' motivation and have them be less performant... 

So what should we do with our specialists?

Let me hazard a guess that you are already thinking something about annual (half yearly, quarterly) objectives in the back of your mind here. If so - go watch the Dan Pink video again and chastise yourself.

One of the key principles in Kanban is to "Respect the current process, roles, responsibilities & titles" (see David Anderson's blog post here)

We should be trying to work on our individual areas of intersection, while still respecting each team member's core expertise. In effect anchor your team members in their core domain of expertise, then look for natural opportunities to increase their areas of overlap into the other disciplines as appropriate.  We should do this in a continuous evolutionary manner, rather than try to revolutionise the way each individual works. Why would we have the QA specialist pull the Work Item that is very heavy on DB work, and pair on it with a regular Developer, while the DBE is forming test cases with another developer. Surely we should have the DBE pairing with someone from another discipline, say a QA, on that Work Item. In that way we are making best use of our expertise to finish the work item, and allowing the DBE to flex his DB mastery while expanding the knowledge of the QA into the DB area while still having them come at the work from the QA perspective and flex their QA mastery muscles. 

This way you are actually feeding their mastery motivator as you are allowing team members to grow their area of mastery, without giving anything up. They still get addressed as the expert in their field, but are able to meet their Purpose driver by being more able to work with and understand the needs and views of the rest of the team. A subtle difference, but one that can make a whole world of difference to the individual team members. In the end, its what the team is able to deliver that matters, so helping the individuals in the team to work better seems like a good idea. 

If you know me, you'll know I'm a fan of both Scrum and Kanban, and get irritated by those who see them as opposing forces. So this post is definitely not me having a pop at scrum. However I do have a problem with the term "Sprint". You'll also know I love a good metaphor. 

As dev teams we often focus on running at full speed, trying to do more faster. Sounds like a good way to eliminate waste and get things done as quickly as possible, but lets have a proper think about it...

A lot of what we are asked to build are big things, and this is where the problem starts for me. 

Lets get to the metaphor. Sprinting comes from athletics, so lets focus on the big one - the 100m sprint. Look at the photo below. The winners of the 100m sprint and the 10,000m at the Olympics this year in London 

In the 100m, the athletes don't take a breath, it is anaerobic activity. Ask an athlete to try to run the 10,000m that way, and you have a doomed project. It is possible for a human being to 100m in under 10 seconds, but it doesn't follow that you can run 10,000m in under 1000 seconds. The world record for 10,000m is 1577 seconds, which is about 50% greater. I suspect that Usain Bolt has never run a 10,000m track race, and if he did, I think it is fair to say he would be significantly slower than 1577s but if he did, I think its a good bet that Usain would be unlikely to run the first 100m in 10s. That pace is the definition of unsustainable pace. 

If you have a software development team approaching their work as a series of individual 'out and out' sprints where they go as fast as they can to deliver software without thinking about the long game, and the quality and the technical debt they are accruing, then they are trying to run a 10,000m like a series Usain Bolt 10s sprints. Mo Farrah might take longer over the first few 100m, but he will run the whole 1000m distance much faster than Usain could. 

All too often we focus on the 'how fast' and forget about the 'how well', but I'm prepared to say that the same people who push us to sprint as fast as we can, would never back Usain over Mo in a 10,000m race. 

The risk of using metaphors is that you stumble into someone else's metaphor. In this case the Scrum Sprint metaphor. I've already stated I'm a fan of Scrum, but Scrum is often implemented badly. As a coach I've had to walk into organisations and help pick up the pieces, so I know this to be true.  If you treat your Scrum Sprints like a series of 100m races, and go on like that for 100 sprints, you will have accrued so much technical debt and a bug list so long that you will no longer be able to deliver any value work in a reasonable timeframe again.

Most of your delivery capability will be tied up dealing with failure demand. A good scrum implementation will acknowledge this, and therefore ensure quality is front and centre where it should be, and spend time every sprint on keeping the bug list down and use refactoring and 'boy scouting' to keep the technical debt down. This means not going as fast as you can out of the blocks doing only new feature work, but it also means that more value work is delivered over the time you're delivering your MMF, and that the pace is sustainable.

A good Scrum team or Agile team must be able to maintain its pace indefinitely. In my metaphor, athletic runners are either 'Sprinters', 'Middle Distance runners' or 'Long Distance runners'. So the same people often  compete in the 3,000m, 5,000m, 10,000m, Half Marathon and Marathon races. They are showing the ability to use their sustainable running pace on varying lengths of race. 

The long distance runner seems to be a better metaphor for most of us to follow than the sprinter. There are situations where the 'out and out' sprint is the right approach - I've heard tell of banking apps that are built very quickly for a single niche purpose, used for a day or so, then discarded. That would suit the 'out and out' sprint as the tech debt and bugs are thrown away with the code, then the team starts afresh. 

So people - lets make sure we are honest to ourselves and our stakeholders about the kind work we are undertaking, and then approach it with a view to the success of finishing the kind of race we are running. 

How did we get to the moon - Part 2

Here's a daft question, which mission first landed humans on the moon? Apollo 11 of course, but lets think about that. It wasn't Apollo 1, it was Apollo 11. What on earth were the other 10 missions costing millions of dollars for then? 

Well, I've had a good think about it, and this is another aspect of I find admirable about NASA's approach. As I mentioned in my last post, they had a backlog, and took achievable chunks from it, and finished them before moving on to the next. 

Mercury was all about getting manned spaceflight, Gemini was what NASA called "a bridge to the moon" - to work out how Apollo could be achieved, and Apollo was about getting to the moon. 

So lets start at Gemini. The mission goals were 

• To subject man and equipment to space flight up to two weeks in duration.
• To rendezvous and dock with orbiting vehicles and to maneuver the docked combination by using the target vehicle's propulsion system;
• To perfect methods of entering the atmosphere and landing at a preselected point on land.

(source NASA)

All of these were the perceived steps needed to prove that a mission to the moon was possible. In a very agile way in 1964, NASA worked out that the original goal to land on land was not needed after all, so the mission was brought to a close early. 

So what did they get from Gemini? They got:

Validated Learning

They got the Validated Learning by delivering real missions. How often have you come across IT projects that are in a 'proof of concept' phase that deliver no real working value. The team gets to have a whale of a time playing with code that "we don't need to QA because it will never go into production" with the aim of getting learning of how to do real work. Only to find out a month later when the real work starts that most of what they learned was invalid, and that reference architecture we built was a bit Mickey Mouse. 

Proof Of Concept still means going live

Not NASA, they built real rockets, with real spacecraft on top, put real people into them and conducted real work that went into production. I can't imagine the rocket scientists saying, "we didn't bother testing the space suit systems properly, because this isn't a production mission to the moon, it's just a proof of concept." The astronauts were going out into the vacuum of space, so everything had to work with quality. 

Gemini had 10 manned space missions in about 18 months. They turned around their iterations quickly in manageable chunks, with the first 4 missions going from 4 hours to 4 days, to 8 days, to 14 days. Goal 1 achieved, two week manned spaceflight, move on to goal 2, docking. Interestingly part of the 14 day mission was a subgoal attempting to dock craft which failed. A lesson in limiting WIP for NASA right there

Keep the team together

The Gemini mission was piloted by names you will find very familiar - Armstrong, Aldrin, Collins, Lovell et al. Names you know from famous Apollo missions (11 and 13 in this case). In other words they had another Agile principe at heart. They built a great team, finished the mission, then kept the team together and brought the next mission to them.

How often do we put together a team for a project then disband it, and put together a new team for a new project? Good agile has teams staying together and work is brought to the high performance team as it completes other work. 

On to Apollo

Similarly with Apollo, each mission was designed to gain validated learning. 

Apollo 1 was a disaster with a fire in the cabin killing all of the crew, which led to changes in the cabin design, and better escape systems. A harsh lesson that led to important learnings for the rest of space flight. As with most projects that go wrong, the lessons we learn tend to be the most important ones. 

Apollo 8 was the first mission around the moon - the furthest away man has ever travelled. 

Apollo 9 was the first time the Lunar Module was tested separately from the Command Module, launching, manoeuvring, and docking in space. 

Apollo 10 was everything up to but not including lunar landing. They launched the Lunar Module and went down to within 9 miles of the surface of the moon, then came back up, docked and came home. 

Apollo 11 was the biggie. Neil may have fluffed his line ( "one small step for a man," is how it was supposed to be) but mankind was on the moon for the first time. 

Apollo 12 onwards was about finding out how man could spend longer time on the moon, and potentially set up a base there in the future - hence the lunar rover etc. 

Each mission built on the learnings of the previous mission, adding another valuable increment of validated learning, until the final objective was achieved. 

This equates to a project releasing valuable increments and evolving through the validated learning gained until you have a Minimum Viable Product to launch to market. Gemini and Apollo 1 through 10 gave the increments and validated learning so that Apollo 11 could happen, and that progressed throughout the programme to the final mission to the moon (40 years ago). 

One Final Thought For Mankind

Can you imagine the Big Bang waterfall approach as applied to the Apollo programme? Imagine if Gemini 1 had to go and land man on the moon with no missions in-between. Do you think it would ever have even taken off? I suspect it would have been cancelled after 15 years of theoretical work, and been an abject failure. They just didn't know all of the things they needed to learn up front, it was only by launching the missions that they found out all of that Validated Learning that made the objective possible. You don't learn everything you need in a theoretical POC phase, you learn by doing things for real. NASA was doing this on the highest profile project in the world in the 1960s. Finishing one small step at a time. 

With the BBC going all Stargazing LiveI thought I would start this blog by sharing some of my space based Agile and Kanban thoughts. Being an amateur astronomer, and someone who naturally seeks out metaphor to help understanding, I do like to draw on the universe to help me explain things.

So how did we get to the moon? Well first of all there was the space race, and NASA started behind the USSR space programme who already had satellites and put Uri Gagarin into space first, but they caught up and overtook the USSR programme. How did they approach their mission? One mantra captures what NASA is about for me:

"Do one thing at a time, with supreme excellence."

For me, this embodies the spirit of Kanban in a way that nothing else ever has. Let me break it down.

Do one thing at a time

Focus on the finishing. Put your effort into releasing your value. All of these things really boil down to Limit your Work In Progress. We have Little's Law to show us mathematically why Limiting your WIP is the most effective thing you can do to affect your Lead Time and your Throughput, but I've never seen such a big and government funded organisation be so single minded in what it did as NASA was (and is).

They started off with a very simple high level backlog of things to do.

• get a satellite into orbit
• get a living thing into orbit
• get a human into orbit and back
• conduct a space walk
• dock 2 spacecraft in orbit
• put man on the moon

Then they worked out that the back of the list was so far away with so many unknowns that they focused on the value they could deliver, and called it the Mercury Programme, which stopped at getting man into orbit.

They then finished the Mercury programme. And that is all they worked on, the whole of NASA finished Mercury and nothing else. Do one thing at a time.

Even now, NASA no longer works directly on the ISS mission, they use subcontracted private space companies, and the Russian space programme to keep that running for them. Now they are focused on getting to mars. How about the NASA JPL (Jet Propulsion Laboratory) which is in effect a different organisation? Well, it did Hubble ST, then the Mars Rovers, then Mars Curiosity, and now it is focusing on the James Webb Space Telescope. Yes some missions run for years (look at Voyager 2 - over 14 light hours away from earth and launched in 1977 - you can even follow it on twitter here ) but their FOCUS is on one thing at a time. Getting things Launched has a slightly more immediate meaning at NASA.

With Supreme Excellence

This sounds simple, and it indeed it is. If you are going to put humans on top of, or in close proximity to rocket fuel and liquid oxygen, and measure the amounts those substances in thousands of tonnes, then you really want to minimise your bugs. In the world of Rocket Science, things seem to either go well, or go catastrophically badly, so you must ensure quality.

In Software Engineering, we say the most expensive time to fix bugs, is when they are live, and earlier we catch them, the cheaper they are. The cheapest time to fix a bug is actually before you write it (pairing sceptics take note).

In space missions, it is often impossible to fix a bug once it has gone live and been found the hard way as evidenced by the price paid by the crews of Columbia, Challenger and Apollo 1 and very nearly Apollo 13.  Do you remember the cost of fixing the initial Hubble Space Telescope focus problem, and the media furore about that bug? If they have similar issues on James Webb Space Telescope, there is no way to fix it. Humans have never been as far away from earth as JWST will be, so once it's there, it cannot be touched by human hand again.

So focus on the quality. I remember my first reading through of David J Anderson's Kanban book, and being somewhat sceptical as that being the place he suggested the readers start.

Then I walked into my first true Kanban implementation at YouView TV, and seeing the sheer amount of bugs my team was generating. Looking back , it would have been easy to have said that the team's primary output was bugs and secondary output was software. Harsh, and probably not really true, but it makes the point figuratively.

So I duly did focus on the quality with the team, and it made a huge difference. I'll probably do a blog on that separately in the future so I'll avoid too many spoilers, but I did track back one small bug. It took only 3 hours to write the whole feature, and if it had taken 3.5 hours, the bug wouldn't have existed at all.  6 months later, it took 3 days to fix the bug. The original developer had left, the rest of the system had moved on, and the cost of (re)working it all out in order to fix the bug rose to 3 days. And of course the down stream integration and system test team also had to spend more effort retesting the bug fix, so there is further hidden cost downstream. What could have cost under 30 minutes of Dev time, actually cost 3 days of dev time plus some other unquantified QA time.

In my career to date, I've never heard an operations / support team complain that the quality of the code delivered was too high, or the business complain that we were spending too little of our development capability on live support and bug fix, or had too little downtime on live systems due to bugs.

People often say that high quality is aspirational, or too expensive. They might even be bright people saying it. It doesn't stop them being wrong. I'm sure Albert Einstein must have came up with some right nonsense from time to time. Let me explain:

Truth be told Quality IS expensive, and the cost is front and centre where everyone can see it and point at it.

However, developing with low quality is MUCH MORE expensive overall, but the cost tends to be hidden, and late in the day, so it can appear to be cheaper up front.

It is always more expensive to fix things later. We all know that intrinsically. Do you top up the engine oil on your car when it needs it, or wait for the engine to blow up? Do you replace your tyres when they are getting low tread, or wait for a blow out at 70mph on the M3? Do you fix a dodgy bit of brickwork on your house, or wait until it falls down? Should you fix the bug now 'in sprint', or wait until the website goes down right in the middle of the peak sale that accounts for 40% of the company revenue for the year? Do you refactor the basket component as you work, or just leave it until the point that no-one working in the company understands it any more so the risk of making a small change means you have to rewrite the entire basket component, and the interfaces it has to all of the other systems?

Do you build your rocket with a high quality approach, or just hope it doesn't blow up on the launch pad?

NASA choose to focus on quality, but still have accidents. Imagine if they didn't focus on quality…

It wouldn't be as catchy to say Limit your WIP and focus on quality, but that is the essence of the message. Do 1 thing and do it as well as you can also works.  If it's important enough to spend money on doing, then don't do anything else, and do it as well as you can. I like to thing everything in Agile & Kanban is plain simple common sense or counter intuitive but still common sense.

I've only talked about costs and throughput in this blog, and I've deliberately stopped myself from 'going off on one' about intrinsic motivation amongst the team, and craftsmanship etc. I probably will at some time in the future but in short, the hard facts of when YouView focused on throughput, my team had 18 'funded heads' but we could only maintain 13 real developers at any given time as every time we found a good one to hire in, another left. When we had a quality craftsmanship focus we had the same 18 funded heads, and we had 18 people working there. Throughput also went from '8' to '13' so we had happier people, and got more done, as well as the higher quality. If you love throughput, forget the throughput and focus on the quality instead. Counter intuitive, but common sense none the less.

If you want to discuss anything about this, please catch me on twitter @KanbanDan