# Friday, 24 October 2014

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. 

Article 2003784 0C951ED400000578 751 233x261

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.

Img 0488

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. 

AXEXGW 1922167c



.
Tags: Agile | Kanban | Quality

Friday, 24 October 2014 14:07:27 (GMT Daylight Time, UTC+01:00)  #   


# Tuesday, 14 January 2014

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. 



.
Tags: Agile | Kanban | Lead Time | Lean | LKU | Quality | WIP

Tuesday, 14 January 2014 12:26:40 (GMT Standard Time, UTC+00:00)  #   


# Friday, 07 June 2013

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

HousesAllUndone

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
I get paid £20 at the completion of each lawn by the homeowner. I have a team of 3 workers:
  • 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
HousesMaxLunch1
 
At the end of day 1, they have finished 4 gardens, and earned me £80 
HousesMaxCoP1
 
At lunch on day 2, they have finished 7 gardens and earned me £140, but have worked on 2 other gardens
HousesMaxLunch2
 
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. 
HousesMaxCoP2
 
 

Now for the Minimal WIP solution for the same problem

I ask the workers to all swarm on the first garden and get it finished. Each worker naturally plays to their strengths and does the jobs they are specialists in whenever they can. When there is no more work they can reasonably do, they move on to the next garden, but we have a WIP limit of 2 gardens. Even with that in mind, we try to work on the same garden together if we can. It's good for finishing gardens, but also good for the morale of the workers to be working together.
 
At lunch on day 1, they have finished 3 gardens and earned me £60
HousesMinWIPLunch1

At the end of day 1, they have finished 6 gardens and earned me £120
HousesMinWIPCoP1

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

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. 
HousesMinWIPCoP2
 
I'll attach my spreadsheet which shows who did what when, I always like to have the data to prove the science.  gardenTimes.pdf
 
So the net result is that the lower WIP lead to shorter Avg Lead Time per garden, and resulted in less effort being spent to achieve the same work completed, and therefore earlier delivery of value and more completed work in the same time period. You could add in that Bob, Ian and Flo are treated like people in the minimum WIP version rather than resources - they got to specialise in their area of mastery whenever possible, and got to work together in the same garden for a lot of the time. That is likely to lead to a happier workforce which tends to lead to lower turnover, and easier recruitment (Bob, Ian and Flo are telling their friends how much they enjoy working here and those friends want to come and work with me too). 
 
Now lets stretch the metaphor… lets imagine we live in a country where we have unpredictable weather (not a big stretch in the UK) and it rains on day 2 so we cannot go to work. In the high WIP method we only finished 4 houses and earned a paltry £80. Most of the value in that method gets delivered on day 2, which never happens. In the minimal WIP method we would have finished 6 houses and earned £120 - thats 75% more value released after day 1 in this scenario. Plus we have unhappy customers with half finished gardens.  
 
I'm sure you're asking yourself how the rain equates to something in the IT world, but I'm sure we've all had days of lost work where networks have failed, the SAN ran out of DISK, the Build Server went belly up or similar. Work in Flight is actually a liability rather than a benefit - it has cost but no value, it only becomes a benefit when it completes and releases its value. We need to shift the focus on the Output of our systems, not the utilisation of our resources within the system. In this case the focus is on finished gardens, not working on gardens.
 
It seems like a magic trick, but there is nothing up my sleeves here - this is just Kanban in action. 
 


.
Tags: Agile | Kanban | Lead Time | Lean | LKU | Quality | WIP

Friday, 07 June 2013 16:36:21 (GMT Daylight Time, UTC+01:00)  #   


# Wednesday, 27 February 2013

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 

Mo Farah and Usain Bolt 2012 Olympics (cropped)

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. 



.
Tags: Agile | Kanban | Lean | Quality

Wednesday, 27 February 2013 11:29:38 (GMT Standard Time, UTC+00:00)  #   


# Wednesday, 09 January 2013

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.

SaturnVSeparation

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



.
Tags: Agile | Kanban | Lean | LKU | NASA | Quality | WIP

Wednesday, 09 January 2013 11:47:39 (GMT Standard Time, UTC+00:00)  #