Karl Scotland – Using Agile to Deliver Value
Lean
A Pattern for Using Scrum and Kanban
Jul 27th
I’ve noticed a pattern that I’ve found myself using recently when I’ve worked with new teams that makes use of both Scrum and Kanban ideas. I’ve already said that I believe the two are complimentary, and this should help show how.
- I’ll often begin with a “Canonical Scrum” implementation. This gives a relatively simple introduction due to the ubiquitous language, standard training and often client demand. I also find that its a very good way of quickly exposing the real underlying workflow. Stressing a team by introducing a new way of working soon makes the current way of working apparent.
- After a few Sprints,once the team understands both what the desired outcome is and the current context is, I’ll ease back into what many people might call “ScrumBut”. Rather than continuing to highlight and struggle against impediments and constraints which are out of the teams control, I will apply kanban aspects to help the team acknowledge, but deal with their context without feeling dogmatic.
- Finally I’ll help both the team and the organisation improve, by seeing where the issues are, whilst continuing to be able to deliver. Sometimes the current workflow is appropriate for the team and it is smaller batches and queues that are needed. Sometimes the current workflow is a symptom of silos and poor collaboration.
So I find Scrum to be a good way of showing teams what could be possible, and finding out where I can help make improvements. Then I find Kanban a good way of enabling a smoother transition for those improvements in a way which is appropriate for the teams’ contexts.
The Flow Experiment
Jul 16th
I put together a small simulation for the SPA Conference this year which seemed to go well, and which I re-ran at the London Limited WIP Society, and hope to run again. You can download the materials, and this is a short write-up of how it works so people can run it and experiment with it themselves.
Overview
The basic aim of the simulation is to solve maths problems. This idea was inspired by Simon Bennett and Mark Summers session The Incentive Trap which also uses maths as the problem domain. The solving of equations introduces variability into the exercise using some simple knowledge work which is hopefully more interesting and engaging than rolling dice.
The maths problems flow through the following value stream:
-
Options
-
Analysis
-
Solve
-
Check
-
Accepts
-
Done
The following roles are involved in the value stream:
-
Analyst
-
Solver
-
Checker
-
Accepter
-
Manager
The following scenarios are used to experiment with the flow:
-
Phase Driven
-
Time Boxed
-
Flow Based
Stages
Options
Each scenario starts with a portfolio of possible problems to solve, in the following format:
| ID | Operands | Solution |
| 1 | 3 | 25 |
In this example we have an option to create an equation with 3 operands and a solution of 25.
Analysis
When an option is selected, it is transformed into an equation during analysis. Rather than expecting participants to come up with their own equations, which could result in trivial equations, a lookup is provided. The equations in the lookup are in a different order to those in the portfolio so some effort is required!
| Operands | Solution | Equation |
| 3 | 25 | 3 * 7 + 4 |
Solve
The equations are then solved independently i.e. the solution is not available
Check
In order to check that the Solve stage produces a correct result, the equation is solved independently again.
Accept
Finally the two independent solutions are compared, along with the actual equation, to ensure it has been solved correctly
| ID | Operands | Solution | Equation |
| 1 | 3 | 25 | 3 * 7 + 4 |
Done
When the correct equation has been independently solved correctly twice, then the problem can be considered Done.
Roles
Analyst
The analyst selects the options from the portfolio, matches them against the available equations, and writes them onto index cards. Each index card should contain the option ID and the equation as follows:
Solver
The solver takes each index card with an equation on it, and solves it. Any intermediate calculations should be written on a separate sheet, and calculators should not be used (although someone who did use a calculator at SPA didn’t seem to gain any advantage!) The answer is to be written on the back of the back of the index card, to the left side, and covered with a small post-it so that is hidden and can’t be copied.
Checker
The checker also takes each index card with an equation on it, and solves it. Again, any intermediate calculations should be written on a separate sheet, and calculators should not be used. this time, the answer is to be written on the back of the back of the index card, to the right side, and again covered with a small post-it so that is hidden.
Accepter
The accepter takes the index card and confirms whether the ID and equation match correctly, and that the two answers are both the same and correct. The they are, the the problem is Done, otherwise they reject it. Each scenario will handle rejection differently.
Manager
The managers job is to keep time, ensure the process is being followed and capture metrics. Every 30 seconds they should count how many of the maths problems are in each stage of the value stream and record it on a worksheet. It is these numbers which can be fed into a spreadsheet to generate a Cumulative Flow Diagram to visualise the flow.
Scenarios
Each scenario is 5 minutes each.
Phase Driven
For a phase driven approach, the team should initially plan how many of the set of options they think that they can complete in the 5 minutes available. Then all the selected options are worked on phase by phase. Thus they are all analysed, then all handed over to be solved, then all handed over to be checked, and finally all handed over to be accepted. Any rejected work can only be moved back to the beginning once everything else has been accepted as Done.
Time Boxed
For the time boxed approach, the team should plan how many of the set of options they think that they can complete in the 1st of the 5 minutes. Those options are then worked on by the team individually. Specialism still applies, but once a problem has been analysed, it can move to be solved, check and analysed without waiting for the whole batch. At the end of the 1 minute time-box, the team should stop, review and re-plan the next minute, deciding how many problems to work on next. This is repeated until the 5 minutes are up i.e. there are 5 x 1 minutes time boxes. Any rejected work can be passed back immediately.
Flow Based
For the flow based approach, the team should pick 1 problem at a time to solve. As with the time boxed scenario, specialism still applies, so once a problem has been analysed, it can move to be solved, check and analysed. However, there should only be one problem in each stage of the value stream at a time, thus creating a pull system. Any rejected work can be passed back immediately (which may result in the WIP limits being broken), or the accepter can pull in the appropriate role to resolve the issue.
Results
The metrics from the managers worksheets can be fed into an excel spreadsheet (included in the download package) to generate CFD diagrams. Here are 3 from one of the teams at SPA.
Phase Driven
Time Boxed
Flow Based
Variations
There are a number of variations I’d like to try.
- One of the things I’ve noticed is that the maths problems may be just a little bit too difficult for some teams, and the take too long sometimes to get any really useful results. One option would be to extend the time for each scenario to 10 minutes to allow more time. I wonder whether this could make it less snappy though.
- The time-boxed scenario never really plays out how I envisaged it. This is partly down to the short time frames. Stopping, reviewing and replanning every minute doesn’t seem right – especially when you can only manage 1 problem in a minute! What i was trying to show was the small-batching nature a time-box can have. One way round this is to explicitly create the batches in a similar way to the Penny Game.
- Some people don’t like the mental exercise involved in the maths! Katherine Kirk described a variation to me where the teams used a “Pictionary” workflow instead. Options –> Describing –> Drawing –> Guessing –> Checking –> Done
- Its quite likely that the Flow scenario comes out “best” because its the last one. It would be interesting to run the scenarios in different orders to see what impact that had. Especially if there are 3 or more teams so that each team can start with a different scenario. This would possibly be more complicated to run, but with enough facilitation could be done.
Feel free to download the pack, which contains:
- Handouts – PDFs of the options, analysis and accepter worksheets for each scenario
- Spreadsheets – one with all the details used to create the worksheets, and one to be used to create the CFDs
- Powerpoint – slides with simple instructions for running the experiment
All I ask is that you let me know how you got on, and what variations you come up with. Here are the SPA results and LWS results.
Does A Kanban System Eschew Estimation?
Jul 14th
I was recently involved in a brief twitter conversation which started when Mike Sutton tweeted:
estimation is not about the number that pops out. It is about exploring effort and discovering that you don’t know stuff.
Paul Dyson responded:
spot on! This is fundamentally what I don’t like about the kanban “if people find estimation hard, don’t make them do it” mantra.
Which is where I jumped in:
where did you hear that “kanban mantra”? Not one I’m familiar with.
Only to be told:
err, it was actually in the talk you gave at mini-Spa!
Since then, Paul has blogged some more on estimation, and this is my response, hopefully clearing up what I said, or at least meant to say at mini-Spa, in addition to what I’ve already written on estimation and waste.
A simple summary and paraphrasing of Paul’s post would be:
Estimation, as part of time-box planning, leads to whole team interaction and collaboration, to create learning about past capability and forecasts of future capability
Lets start by drilling into these key points from Paul’s post. Essentially the implication is that by eschewing iteration, we cannot have whole team interaction and collaboration, cannot learn about past capability and cannot forecast future capability.
Whole team interaction and collaboration
I can think of 3 ways a team a whole team can interact and collaborate around planning a new piece of work without estimating in a time-box planning meeting:
- Cadence. The team agrees a cadence at which they will all get together to collaboratively plan new work. This planning cadence looks at what new items the team may be able to pull, given their current work-in-process, rather than estimating what items they may be able to complete.
- Workflow. The team explicitly models there workflow to make transparent that fact that they need to get together to plan new pieces of work when they are pulled. This stage could be a stage called “Planning”, or even ”Analysis”!
- Just do it! When the team pulls a new work item, they spontaneously swarm on it to plan it. This probably requires a small and high performing team.
Even so, this is assuming the whole team really does need to interact and collaborate on every piece of work. However, not every piece of work is equal, and there may be some smaller, simpler features that can be planned and delivered by a smaller group.
Create learning about past capability
We can learn about our past capability by measuring data such as cycle time, and tracking it with a Statistical Process Control chart. Common cause variation is to be expected within a stable system. However, special cause variation is something we can look at in more detail to see what we can learn (as long as we don’t change the system in response to special cause variation).
Forecast future capability
Once we understand our past (or current) capability we can use that information to forecast future capability. By understanding how long things have typically taken in the past (with natural variability) we can determine how long things will take in the future (with natural variability). Dennis Stevens has recently written some great posts discussing knowing when we will be done, using classes of service and service level agreements to manage variability.
So kanban teams do not eschew estimation simply because it is hard. Some teams choose not to estimate because they can realise the same benefits that estimation gives with a lower cost. The old joke does still apply (“Doctor, Doctor it hurts when I do this”, “Don’t do that then”). If it hurts to estimate, then find other ways to encourage whole team interaction and collaboration, learn about past capability and forecast future capability. On the other hand, if estimation doesn’t hurt, or costs too much, then it may be the right thing to do in your context.
What I think we do agree on is that when we are planning, we should decompose work for understanding, rather than sizing (thanks to Eric Willeke for this phrasing). As Mike says, the estimate is just a number that pops out of the discovery.
Kanban and Scrum – Intention and Implementation
Jun 17th
In my last post I introduced the idea of a PVC System – one which exemplifies Pull, Value and Capability – and closed by posing the question as to whether Scrum could be considered to be a PVC System. In answering that question myself, I realised that there is another distinction which I will describe in this post. In doing so, I am also re-entering the great Kanban and Scrum debate, with the goal of learning rather than fighting!
The XP Community popularised the concept of programming by intent; writing code which describes what it is doing rather than how it is doing it (programming by implementation). I believe the same distinction can be used to describe methods, and can help differentiate Kanban and Scrum. Kanban is an intention-revealing method. The intention is to reveal the workflow, visualise the work, limit work in progress, establish a cadence and continuously improve. How to do that is up to the team. They can use any workflow, visualisation, WIP limits, cadence or improvement mechanisms. Scrum on the other hand is an implementation-revealing method. The implementation is described in terms of the Sprint and the associated roles, meetings and artefacts. Even if the implementation is described in abstract terms, as Tobias Mayer does, (and Tobias’s interpretation of Scrum is one I respect greatly) I still consider it to be focussed on implementation.
This is not to say one is better than the other. An implementation is ultimately required, and Scrum has proven to be a very good one with which I have had considerable success. But is Scrum a PVC System? I think it can be, if implemented with an intention-revealing mindset. If the Sprint, roles, meetings and artefacts are implemented in way which reveals the workflow, visualises the work, limits work in progress, establishes a cadence and continuously improves, then it will be implemented with the right intent. I expect that most cases of “Good Scrum” will fall into this category. On the other hand, if the Scrum Sprint, roles, meetings and artefacts are implemented in a mechanical way, then I suspect that the workflow will remain hidden, the work will not be visualised, work in process will not be limited, a cadence will not be established, and continuous improvement will not happen. This is when we get cases of “Bad Scrum”. Thus ScrumBut is not when the Scrum practices aren’t followed per-se, but when they are followed with the wrong (or no) intent.
So Kanban and Scrum are like apples and oranges (to jump to an different analogy). Both are good for you, and both can go together – with other fruit – to create a tasty fruit salad. But they are different. Kanban is intention-based and Scrum is implementation-based.
From KFC Development to PVC Systems
Jun 14th
I’ve been revisiting my earlier KFC Development work in light of my more recent focus on five primary practices. This is an brief overview of what’s changed, and what my mental model looks like now.
Firstly, I’ve stopped referring to the practices as such, in favour of calling them aspects. Practices always felt slightly wrong, but at the time I couldn’t think of a better way of describing what I wanted to be practical, rather than theoretical points. I think aspects still allows that practical focus, without giving the impression of being a prescriptive process. So the aspects are:
- workflow
- visualisation
- work in process
- cadence
- continuous improvement
How does the KFC triad fit into that then. Here’s my thought process, which focusses more on conceptual ideas.
- Kanban. In this context, Kanban is the tool. As I have become more interested in Systems Thinking, I have become less focussed on the tool. What is more important is the concept behind the tool. Kanban is a great way to create a pull system, but there are others; drum-buffer-rope and CONWIP are a couple. Kanban seems to be the one that’s easiest to explain, and the one that caught people’s imagination, but really its about Pull.
- Flow. Given the first concept is Pull, and we should flow where we can and pull where we must, then I think Flow comes under the concept of Pull. What I tended to find myself talking about with Flow, however, was what should flow. There’s not point having a pull system where work flows smoothly if the work is useless, so the second concept is really about Value.
- Cadence. Having identified Cadence as a Aspect, it can’t really be a concept as well. I talk about Cadence as a means of achieving predictability and reliability and of demonstrating capability. Cadence is just one way of doing this however, so the third concept is really about Capability.
So instead of KFC Development, I have moved to thinking of a Kanban System as a PVC System – one which exemplifies Pull, Value and Capability, and that can be described in terms of workflow, visualisation, work in process, cadence and continuous improvement. I quite like the ‘plasticity’ metaphor that springs to mind with this new triad; “the capability of being moulded, receiving shape, or being made to assume a desired form”. Its probably not very environmentally friendly though!
For me this also leads to the question of whether a process (such as, for example, Scrum) is a PVC System. That’s the subject of another blog post though!
A Kanban Multiverse – not from LeanSSC Atlanta
Apr 21st
I should have been at the LeanSSC Conference in Atlanta this week, but unfortunately Eyjafjallajokull intervened. This is the Prezi I was going to use. It may not make much sense on its own but hopefully gives a flavour of what sort of things I was going to talk about. I’m hoping to put together a post together to flesh out the details.
Update: I posted a write-up on the Management 3.0 site
Defining the Last Responsible Moment
Apr 6th
I was involved in a recent twitter discussion with Chris Matts about Lean’s “Last Responsible Moment”, and he set a challenge to come up with a usable definition. Chris’s opinion is that there isn’t one, compared to the Real Options equivalent. This then, is my response to that challenge.
I will define the Last Responsible Moment (LRM) in terms of Cost of Delay, as used by Don Reinertsen, and Benefit of Delay, a related term that came up in an email conversation with Julian Everett. In short, the Last Responsible Moment is just before the Cost of Delay outweighs the Benefit of Delay. Its not necessary to be able to quantify the costs and benefits very accurately because any evaluation is going to be better than none!
In his challenge, Chris used the example of knowing the Last Responsible moment to submit a session for Agile2010. I’ll use that example to explain my definition.
Firstly, the Cost of Delay for submitting to Agile2010 goes up at the submission deadline, because when you can no longer submit, can can no longer get accepted, and thus can no longer receive speaker benefits including conference registration, complimentary hotel nights. However, that does not make the submission deadline the LRM, because there is no benefit in delaying submission due to the open commenting and review process. Thus the LRM is actually as soon as the submission system opens. From then on, submitters are losing the opportunity to improve their submission.
What would happen if the Agile2010 submission process wasn’t as open or iterative? In that case, then there would be benefit in delaying, because it would allow more time to refine a submission before entering it. The Benefit of Delay would drop off just before the deadline, however, so the LRM would be then.
A third scenario, as suggested by Chris, is that a speaker might have something so important and valuable to say, that the Benefit of Delay doesn’t actually drop off at the submission deadline. There may be a Benefit right up to the conference itself because a speaker can turn up with a Soap Box, or propose a session for Open Space. The Cost of Delay remains the same, due to the loss of speaker compensation, but the Benefit might always outweighs the Cost.
Finally, in this scenario, a speaker might choose to register for the conference early anyway to take advantage of any early bird deals, and book flights and hotels early to get good prices. This would reduce the Cost of Delay, and thus potentially reduce the Benefit needed to make it worthwhile not requiring an official speaking slot on the program.
To summarise, understanding both the Cost of Delay and Benefit of Delay can be a practical way of defining the Last Responsible Moment. Real Options thinking provides ways of influencing the Costs and Benefits of Delays to gain some flexibility.
Facilitating A Kanban Konversation
Mar 24th
As I mentioned in my Scrum Gathering Musings, I came up with a twist on the Goldfish Bowl format which I used during the Kanban Exploration Deep Dive. Here are some more details.
The Goldfish Bowl format works really well for facilitating a focussed discussion with a large number of people. It keeps the active voices to a manageable number, while being open for anyone to join in if they have something to add. Apart from providing a solution to my challenge – keeping a spirited debate under control – it also seemed appropriate that the limited number of chairs provided a means of limiting “Voices In Conversation”.
However, there was one thing about the Goldfish Bowl which didn’t seem appropriate. With a Goldfish Bowl, when someone wants to join the discussion, they fill an empty chair as part of the conversation, and force someone to leave to free up a seat again. That seemed to be like “pushing” in to the discussion. What it no-one wants to leave? So instead, I moved the empty chair out of the discussion, and made it a Queue. If someone had something to contribute, they could fill the “Waiting to Talk” seat, which would be a signal to the “In Conversation” people that one of them should leave when ready. I was pleased to find that this change worked really well. Rather than the discussions being interrupted when people moved around as they figured out who would leave, the conversations flowed smoothly as people moved in and out naturally. Initially the “Waiting” person had to wait some time, but once we got used to the system, this seemed to be less of a problem.
These are the instructions I used:
- 4 “In Conversation” seats and 1 “Waiting to Talk” seat
- Only “In Conversation” people may speak
- If you want to join the conversation, fill the “Waiting to Talk” seat (if it’s empty)
- When someone “In Conversation” leaves, that is a signal to move from “Waiting to Talk” to be “In Conversation”
I wondered whether we would evolve the system, by increasing or decreasing the number of seats in each state, but that didn’t happen. Its something I’ll look out for in the future. I’d also love to hear if anyone uses this format, or has already done something similar.
Systems Thinking, The Vanguard Method and Software Development
Feb 25th
I’ve recently read John Seddon’s “Freedom from Command and Control“, which introduces his approach to Systems Thinking – the Vanguard Method. A few key points really struck home with me and helped clarify my thoughts on some of the challenges I’ve come across recently.
First is the following simple diagram, which shows that Management is responsible for defining the System, which is ultimately what defines Performance. Management’s role should be to analyse Performance, and change the System to improve it.
Agile initiatives are usually begun in order to improve performance. Seddon says that in order to analyse Performance, we first need to understand the Purpose of the System. Then we should create Measures to provide knowledge of how well we are meeting that Purpose, before finally applying a Method which meets that Purpose, using the Measures to help refine the Method.
Finally, Seddon says that understanding Purpose involves understanding Demand, and in particular, Seddon introduces the concepts of Value Demand and Failure Demand. Value Demand is what do our customers ask us to do because it add value, and Failure Demand is what our customers ask us to do because we failed to something, or do something right in the first place.
I’m increasingly aware of Lean and Agile methods being used for the sake of it. While Scrum, XP and Kanban will generally serve common software delivery Purposes, such as delivering real benefits and in short timescales, using them without recognising the Purpose will often result in no real improvement in Performance. Lean and Agile methods are often used just as alternative delivery approaches within an existing System, rather than as means to change the System itself. These organisations can be thought of as “wall-dwellers”, using a method within existing boundaries, rather than “wall-movers”, moving the boundaries to help create a System which helps meet the Purpose. To quote (or paraphrase) Russell Ackoff, this is “doing the wrong thing righter, rather than doing the right thing”.
Do you know what the Purpose of your software development process is? Do you have Measures about capability against that Purpose? Do you know what your Value and Failure Demand is?
Process Safeguards and Ski Slopes
Jan 8th
One of the joys of working as a coach for EMC Consulting are the regular opportunities to have deep conversations on various topics with my colleagues when we are in the office together. For example, earlier this week myself and Simon Bennett began to discuss way of talking to our clients about process such that we can guide them towards the most appropriate choice. However much we may have our preferred approaches, they may not always be the best solution in any context. In the course of the conversation we compared various styles including waterfall, scrum and kanban, and looked at them on various scales, including risk, reward and control. None of these seemed satisfying as a language to use, until Simon suggested safety.
Different processes have different levels of safeguards built into them. Safeguards are used by processes to compensate for low skill, low maturity or low trust, but they also reduce speed or reward. With a waterfall process, the heavy up-front documentation is a safeguard to compensate for low trust (and often low skill and maturity). When a customer does not want to collaborate, then waterfall provides safeguards aimed at avoiding them rejecting the final delivery (not that those safeguards always work!). At the other end of the spectrum, extremely productive teams often have very few safeguards because of the high trust, collaboration and capability. Those safeguards that are in place (such as automated tests) are very different. Not having safeguards doesn’t make the process dangerous. It means that team doesn’t need them. So when we talk to customers about process, we can talk about the appropriate safeguards needed for the amount of trust that exists, the capability of the team, the desired delivery speed etc.
While exploring this idea, I became aware that at various points I was referring to kanban at different places on the safeguard continuum. At the high safeguard end was a kanban based process that looked like waterfall, but was limiting WIP and reducing queue and batch sizes. At the low safeguard end was a kanban process with extremely low WIP, no estimation and pure pull. That’s quite a wide range of processes. Similarly, we had Scrum down as a range on the continuum. Towards the high safeguard end, Scrum-but changes Scrum to add safety. Towards the low safeguard end, a highly productive Scrum team will just be using the raw essence of Scrum. Even at this end, however, the Sprint boundary in Scrum could be seen as a safeguard. It’s the opportunity to pause and reset if things are going awry.
In trying to articulate the different types of kanban system in terms of safety, I gave a nod to XP and labelled low-safety kanban “Extreme Kanban”, and high-safety kanban “Safe Kanban”. Not entirely happy with this we bounced some more ideas around and came to the Ski Slope metaphor. “Extreme Kanban” became “Black Kanban” and “Safe Kanban” became “Blue Kanban”. A further iteration led us to “Off Piste Kanban” and “Nursery Kanban”. The ski slope metaphor works quite well at a number of levels. Its a nice way of looking and risk and reward. As a beginner at skiing I don’t want to take much risk, but can get some reward on the nursery slopes. As my capability improves, and as I trust my ability (and instructor) more, I’m prepared to go onto more difficult runs and take more risk to get more reward. Nursery slope groups are generally more controlled, staying in a single file group. As capabilities improve, individuals are given more freedom to try things out for themselves. If I were ever to become an expert, I’d be happy to go off piste to get a high reward. Additionally, when I get to a level where I go off piste, I probably don’t need an instructor anymore, but I may need a guide.
Using the ski slope metaphor allows us to decide what level of process to start a new team with based on how good they currently are. We may want to stretch them a bit, but we may not want them to go straight onto a black run process. We also want the team to be able to move up to more challenging but rewarding levels as they improve. This is one of the reasons I prefer a kanban based approach. I believe it allows teams to start with an safer process to begin with and move to more rewarding processes later by removing or changing safeguards, as opposed to pushing teams straight into a process with less safety before they are ready.
