Agile Process

Kanban paradox

iStock_000014068443XSmall-2017-10-31-14-08.jpg

For a while now I’ve been seeing a paradox with Kanban. Specifically, Kanban compared to Scrum.

For a team new to Agile – although some regard this as heretical I place Kanban under the Agile umbrella, yes I know its more about Lean than Agile but of cause Agile is itself a Lean method, anyway…

For team, specifically a software team, looking to adopt a new process there is a choice:

  • Kanban has a very low barrier to entry, to get started Kanban essentially says “visualise your work and manage the result.” Starting Kanban can be as simple as putting up a board and tracking work items. In Kanban visualisation should drive improvement. Change can be incremental and gradual. Change is rooted in learning.
  • Scrum has a far higher barrier to entry: essentially Scrum says, “Adopt Sprints, designate a Product Owner, appoint a Scrum Master and build out a backlog.” Once these changes are done you can run with Scrum and then the Scrum Master and retrospectives will kick-in and drive further improvement.

Interestingly, neither method says explicitly “Improve your quality.” Yet I always believe a lot of the success of Agile methods is down to good old quality improvement: writing fewer bugs and having fewer bugs to fix means greater predictability and more time to deliver valuable software. But I digress.

It is easier to start with Kanban because it requires less up front change. However that does mean the improvements are slower coming.

Conversely, Scrum drops in, changes a lot and most teams see an immediate improvement. Scrum relies less on subsequent change.

Because Kanban relies more on ongoing change it is more difficult. It is easy to get stuck at the “we built a Kanban board so we are doing Kanban stage.” Change in Kanban requires one to see the need to change, understand what will fix a problem and then follow the change through. That often requires experience. Thus in teams adopting Kanban there is a greater need for a coach, a consultant, someone who has done it before.

Scrum on the other hand makes far more changes upfront and the recipe for improvement is more straight forward. And of cause there are a lot more books on Scrum, blogs on Scrum, Certified Scrum Masters and Scrum experience out there. So while it is harder to get started with Scrum (because more needs to change) there is less need for further change and you change does not require the same level of knowledge.

You see this specifically when you look at statistics. Watching the numbers should be important in both processes but with Kanban it is near essential. Anyone with real understanding of Kanban knows that queuing theory, lead times, possibly weighted lead times, and a bunch of other numbers need to be examined.

Scrum on the other hand doesn’t go much further than a burn-down chart. Yes, making more improvement with Scrum will also benefit from understanding lead times, queuing theory and the rest but you can quite happily use Scrum, and even improve Scrum, a fair bit without understanding these ideas.

So here is the paradox:

It is easier to start with Kanban than it is Scrum without expert knowledge, but it is harder to improve Kanban than Scrum without expert knowledge.

In many ways I prefer Kanban but I find this need for expert knowledge troubling. I suppose I shouldn’t, I’m a consultant, I am that expert, people hire me to help improve their Kanban processes so it does make more work for me.

In the longer run, the Kanban approach is more likely to lead to a genuine all inclusive culture of improvement and is less likely to get stuck in a sub-optimal position – yes Scrum fixes things, but is it the best fix possible?

Looked at like this gives me a new perspective on Xanpan.

I wanted Xanpan to be two things:

  • An understandable description of actually following an Agile process, specifically a Kanban/XP hybrid processes
  • An example of how, and why, teams should create their own processes.

The same paradox is here: Xanpan should be easy to start but allow you to improve; creating your own process requires a bit more knowledge that only really comes with experience.

To step back a minute and ask another question: What amount of change can a team handle to start with?

I find that I advocate more initial change than I used to. Because I’m fearful of creating a learned dependency I really want teams to learn to change and improve themselves. But… once a team has decided to change I want to seize the opportunity and install a bunch of changes while enthusiasm is there.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Kanban paradox Read More »

Utilisation and non-core team members

SplitMan-2017-09-25-10-06.png

“But we have specialists outside the team, we have to beg… borrow… steal people… we can never get them when we want them, we have to wait, we can’t get them enough.”

It doesn’t matter how much I pontificate about dedicated, stable, consistent teams I hear this again and again. Does nobody listen to me? Does nobody read Xanpan or Continuous Digital?

And I wonder: how much management time is spent arguing over who (which individuals) is doing what this week?

Isn’t that kind of piecemeal resourcing micro-management?

Or is it just making work for “managers” to do?

Is there no better use of management time than arguing about who is doing what? How can the individuals concerned “step up to the plate” and take responsibility if they are pulled this way and that? How can they really “buy in” to work when they don’t know what they doing next week?

Still, there is another answer to the problem: “How do you manage staffing when people need to work on multiple work streams at once?”

Usually this is because some individuals have specialist skills or because a team cannot justify having a full time, 100%, dedicated specialist.

Before I give you the answer lets remind ourselves why the traditional solution can make things worse:

  • When a resource (people or anything else) is scarce queues are used to allocate the scarce resources and queues create delays
  • Queues create delays in getting the work done – and are bad for morale
  • Queues are an alternative cost: in this case the price comes from the cost-of-delay
  • Queues disrupt schedules and predictability
  • In the delay people try to do something useful but the useful thing is lower value, and may cause more work for others, it can even create conflict when the specialist becomes available

The solution, and it is a generic solution that can be applied whenever some scarce resource (people, beds, runways):

Have more of the scarce resource than is necessary.

So that sounds obvious I guess?

What you want is for there be enough of the scarce resource so that the queues do not form. As an opening gambit have 25% resource more than you expect to need, do not plan to use the scarce resource more than 75% of the available time.

Suppose for example you have several teams, each of who needs a UX designer 1-day a week. At first sight one designer could service five teams but if you did that there would still be queues.

Why?

Because of variability.

Some weeks Team-1 would need a day-and-a-half of the designer, sure some week they would need the designer less than a day but any variability would cause a ripple – or “bullwhip effect”. The disruption caused by variation would ripple out over time.

You need to balance several factors here:

  • Utilisation
  • Variability
  • Wait time
  • Predictability

Even if demand and capacity are perfectly matched then variability will increase wait time which will in turn reduce predictability. If variability and utilisation are high then there will be queues and predicability will be low.

  • If you want 100% utilisation then you have to accept queues (delay) and a loss of predicability: ever landed at Heathrow airport? The airport runs at over 96% utilisation, there isn’t capacity to absorb variability so queues form in the air.
  • If you want to minimise wait time with highly variable work you need low utilisation: why do fire departments have all those fire engines and fire fighters sitting around doing nothing most days?

Running a business, especially a service business, at 100% utilisation is crazy – unless your customers are happy with delays and no predicability.

One of the reasons budget airlines always use the same type of plane and one class of seating is to limit variation. Only as they have gained experience have they added extras.

Anyone who tries to run software development at 100% is going to suffer late delivery and will fail to meet end dates.

How do I know this?

Because I know a little about queuing theory. Queuing theory is a theory in the same way that Einstein’s Theory of Relativity is theory, i.e. it is not a theory, its proven. In both cases mathematics. If you want to know more I recommend Factory Physics.

So, what utilisation can you have?

Well, that is a complicated question. There are a number of parameters to consider and the maths is very complicated. So complicated in fact that mathematicians usually turn to simulation. You don’t need to run a simulation because you can observe the real world, you can experiment for yourself. (Kanban methods allow you to see the queues forming.)

That said: 76% (max).

Or rather: in the simplest queuing theory models queues start to form (and predictability suffers) once utilisation is above 76%.

Given that your environment is probably a lot more complicated then the simplest models you probably need to keep utilisation well below 76% if you want short lead times and predictability.

As a very broad rule of thumb: if you are sharing someone don’t commit more then three-quarters of their time.

And given that, a dedicated specialist doesn’t look so expensive after all. Back to where I came in.

Read more? Join my mailing list – free updates on blog post, insights, events and offers.

Utilisation and non-core team members Read More »

Blue White Red – a simple Agile process

My article from last months ACCU Overload is now on my website. This piece describes a simple Agile process which I have used successfully. I don’t claim it introduces anything new or radical. I don’t even claim originality, it derives from SCRUM and XP. All I claim is it worked for me, my teams and has been used in multiple organizations.

What I think is important about Blue White Red is that is shows how you can start to roll-your-own Agile-like process. Start simple with what works for you.

Read the full piece here.

Blue White Red – a simple Agile process Read More »