Take-away #3 from David Anderson’s Kanban Coaching workshop.
A discussion of Kanban can only go on for so long before the subject of the Theory of Constraints comes up. In this post I’ll try to explain just enough to show this connection.
Theory of Constraints (TOC) is a large subject that I was first introduced to some time ago by Pascal Van Cauwenberghe and his explanation of the 5 focusing steps for process improvement. Since then I’ve seen TOC pop up at a few Agile conferences. The most notable aspects that tend to be discussed are the 5 focusing steps mentioned earlier and the TOC thinking tools. The Thinking tools offer techniques for root cause analysis, problems solving, conflict resolution and planning. While there have been a number of books explaining these techniques the source material is a set of novels written by Eliyahu Goldratt the first being The Goal: A Process of Ongoing Improvement
.
David’s first book (Agile Management for Software Engineering
) was focused on applying TOC in a software engineering context so I guess it’s not surprising that he wold choose to spend a little time explaining the connection between Kanban and TOC.
At this stage I should say that where David has applied TOC he has subsequently realised that a Kanban approach would have led to an equivalent result and is a conceptually more simple approach.
The areas of TOC that David chose to focus on were the classification of bottlenecks and the application of Goldratt’s 5 focusing steps. Read the rest of this entry »
Take-away #1 from David Anderson’s Kanban Coaching workshop.
Kanban (as applied to software development) has created something of a buzz over the past few years growing out of a couple of case studies of David’s along with the experiences of the likes of Arlo Balshee now we have many more experiences from a variety of contexts.
Given this it was interesting to reflect on why a Kanban approach might be right for a team or organisation looking to adopt an agile way of working.
David highlighted a number of reasons why Kanban might be the right approach including:
- Optimising an existing process is easier and more effective than trying to introduce a new one
- Provide what execs want
- Achieving high maturity
The first of these points challenges the approach that many process improvement initiatives have taken in providing new job titles, new process, new document templates and more. By contrast where an organisation has an existing process, possibly with specialisations and tooling in place, a Kanban initiative would seek to model existing workflows and expose issues leaving job titles and working methods intact. This approach is likely to meet less opposition since it cut’s less to what individual contributors care about and identify with. In addition a Kanban system should generate metrics that inform further improvements, for example to working practices. With luck, by this point sufficient buy in will have been achieved to minimise objections.
The second point cuts to one of David’s mantra’s. Exec’s, he asserts, all want the following:
- Predictability
- Business Agility
- Good governance
In addition David likes to emphasise
- Empowerment without loss of control
- Self organisation without fear
Two aspects of David’s approach to applying Kanban appear to contribute a great deal to keeping these promises. The first is an emphasis on metrics. Particularly where an electronic tool is employed a Kanban system can inform a wide variety of management decisions. This is often missing where agile teams rely on a more emotional output from retrospectives. The second aspect is the exposing of policies. Many classes of issues that constrain the performance of development teams can be described as policies. Once de-personalised these can be considered with respect to the risk that they serve to mitigate and the benefit they bring as contrasted to the over-head.
And finally we come to the maturity argument. A high maturity organisation will be able to; make statistically defensible decisions, implement causal analysis and resolution and effectively deploy process improvements.
While a Kanban system will provide a rich set of metrics and enables the application of a great deal of knowledge accrued in the management of pull systems, it’s great strength (from my perspective) is process improvement. A Kanban system will make any mismatch in capacity between specialists visibile. The board can be annotated with information regarding blocking issues. But, best of all, where a blockage occurs the Kanban system will release resources to deal with the constraint.
Given this focus it seems likely that a Kanban approach may appeal to a class of organisation who see little appeal in more developer centric approaches. Kanban offers a tool set for the management of knowledge work. However, while Scrum and XP expose trust and respect as key principles these remain a choice for the manager applying Kanban.
OK, I’m a little slow on the uptake here since “real work” is proving to be something of a distraction.
Last month I was fortunate enough to attend David Anderson’s Kanban Coaching Workshop. Here is how David described it:
This 3 day workshop is for experienced Agile coaches, existing Kanban practitioners, and those who have previously taken David J. Anderson’s Kanban class. This workshop is intended to be an interactive collaborative session designed to facilitate knowledge sharing and learning. The class will be divided into approximately 10 sections with a slide presentation or tutorial from David to introduce each section. The goal is to enable participants to go back into the field and successfully coach Agile/Lean transitions using the Kanban approach. Each participant will received a personal recommendation from David J. Anderson as a result of participating in the class.
The three days were run in a very interactive style with 8 delegates including myself. Since all of the delegates were either Kanban practitioners or practicing agile coaches the discussion was both lively and in depth.
Subject matter covered a wide range including:
- Motivations for introducing Kanban
- Getting started with Kanban
- Comparing Agile and Lean decision making
- David’s “recipe for success”
- Reviewing David’s Microsoft XIT case study
Rachel Davies has already blogged some of her isights from the workshop here and I plan to add a few of my own key take-aways over the next few posts, these will be grouped under the Kanban Coaching tag.
SCRUM and Kanban (as applied to software development) are different. Proponents of the two drift from staunch opposition to declaring Kanban as a special case of Scrum.
I have been practising and coaching Scrum for a number of years and I delight in the effect it has on project teams. While I practice Scrum I find that Lean Thinking can both help me communicate Scrum and help teams to become more effective in applying Scrum. This way of thinking led to me becoming interested in Kanban a year or so ago since when I’ve being most concerned with where I ought to recommend Scrum and where Kanban.
Recently I have spent time with maintenance groups for whom Scrum would be a poor fit. Kanban offered me an alternative when the client was leaning towards a ScrumBut implementation.
There are some fundamental differences between early project / product development work and the later stages and I don’t see this as a problem. Toyota themselves hold two separate approaches. The Toyota Production System (TPS) is the most widely known Lean Manufacturing implementation. This is the world of work cells, standardised work, Kanban boards and Andon lights. However, when Toyota want to create something new they use the Toyota Product Development System. This approach focuses on a chief engineer holding a vision and rallying a team around him. High bandwidth communication, discovery and experimentation are the order of the day.
So back in a software development context Scrum was designed to manage uncertainty and complexity, to foster high band width communication and seems a valuable fit for early development.
Corey Ladas in his ScrumBan Book declares the following Axiom for applying his application of Lean to software development
Axiom 2: It is possible to develop any value adding increment in a continuous flow from requirement to deployment
Corey makes it clear as he progresses that this well defined workflow is critical to his desired approach. In a new development that workflow is often not known and usually not linear. Rather the team swarm over the requirement often returning to the customer for feedback before offering a completed deployable feature.
My suggestion is this, Scrum is a powerful approach to managing uncertainty as well as being a supportive environment for building a team. I believe that one goal of product development should be to reduce the uncertainty and evolve the workflow. As adding features becomes more straightforward we may find that we are in a state akin to production and can take advantage of a Kanban approach to further optimise for reduced cycle time, increased throughput and just in time scheduling.
July 28th, 2009 in
Agile,
SCRUM | tags:
Agile,
Kanban,
SCRUM |
1 Comment
Karl has offered this post explaining the difference between a task board and a Kanban board.
He draws attention to the common task board focus of tasks to do this iteration. No WIP limit, only tasks currently in development.
This differentiator becomes less apparent when we look at how teams develop their use of task boards. Personally one of my prime reasons for using a white board over an electronic tool is to open up the possibility of the team changing the layout.
It is common for teams to apply the mantra, don’t start something new if you can support an existing activity. In addition to, always ensure that you are working on the highest priority story to which you can contribute. While this is not a fixed WIP limit it does reduce the work in progress in terms of both tasks and stories.
It is also quite normal for a team to choose to show upcoming stories where early analysis is due in preparation for a sprint. Add to this a column for acceptance testing, again not unusual, and we begin to see similarities.
I really appreciate the contribution that the Kanban community have made to our collective body of knowledge. However, it may be beneficial for them to more openly recognise the broad overlap in values between Kanban practitioners and the rest of us agile folks.
May 27th, 2009 in
SCRUM | tags:
Kanban |
No Comments
Karl Scotland has proposed an agile workflow to counter some of the waterfall like connotations apparent when we look at a Kanban board.
So for each feature, one by one, we end up with:
Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate
Does that still seem like a waterfall process?
I think that Karl’s reasoning is sound and I have used similar workflows with SCRUM teams to ensure that they keep the entire value stream in view.
However, before I go on to describe the workflow I am currently using I should stress what this workflow is.
A feature workflow is just that. The feature goes through a number of states from the lightbulb moment to deployed, in use and generating value. A workflow in kanban does not mandate hand-offs between individuals. Equally there is no demand that the team do not swarm over the feature ensuring it travels smoothly and quickly between states.
As Karl states, it is common for SCRUM teams to visualise features as being to-do, in progress and done. I tend to add a couple more states in order to visualise the product backlog; it is nice to have items at the top of the product backlog that are ready for development to pull, everything else on the backlog is simply identified.
So, I have: Identified, Ready for dev, To-do, In-progress, Done.
To tidy this up a little more I can say: Identified, Ready for dev, Committed, In progress, Dev Done.
Again Karl identifies the fact that if it’s not deployed then it’s not generating value. I also tend to work in environments where there is more to do between Dev done with it’s automated unit and acceptance tests and go-live. I’m not saying this is ideal of even that it’s an end state but I am currently looking at workflows a little like this:
Identified, Ready for dev, Committed, In progress, Dev Done, Iterative test done, QA accepted
Where iterative test is an ofset risk mitigation exercise including exploritary testing, some performance assurance and anything else that we can’t pull into the iteration but we’d like to get feedback on ASAP. QA is just that, if we’ve done everything right then there will be nothing coming back from QA.
Of course a workflow like this provides me with the opportunity to visualise work in progress using cumulative flow and to identify bottlenecks. Don’t forget, this is a SCRUM team, we batch 2 weeks work into an iteration because right now that is helping us. Maybe one day we’ll decide to go towards single peice flow but not today.
February 26th, 2009 in
SCRUM | tags:
Kanban |
No Comments
