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 [...]
November 24, 2009 - 10:01 pm
Tags: Continuous Improvement, Kanban, Practices
Posted in Lean | 2 comments
When talking about Kanban Systems for Software Development, I always try to emphasis that the Kanban System is more than the tool, and is a System that should be owned by the team, rather than being imposed upon it. By owning it, and being part of creating it, a team are more likely to evolve [...]
November 5, 2009 - 4:45 pm
Tags: Kanban, Outcomes, Scrum, Sync Steps
Posted in Agile, Lean | 4 comments
I met up with Jean Tabaka last week for a coffee and we chatted over various things, including Lean, Kanban, “The Don”, Tufte, and Systems Thinking. One of the other areas was around the origins and original intents of Scrum. Jean mentioned an early paper(*) by Jeff Sutherland, written before the current terminology became standard, [...]
October 20, 2009 - 5:55 pm
Tags: FAQ, Kanban, Labeling, Scrum, Understanding
Posted in Agile, Lean | 17 comments
Firstly, this post is not an attempt to be divisive or competitive. Instead it is meant to be exploratory. What would it mean for the statement in the title to be true? Actually, the full statement was “People have so misunderstood Scrum, that they’ve reinvented it and called it Kanban”. It was made by Jim [...]
October 12, 2009 - 8:41 pm
Tags: Kanban, Software East
Posted in Announcement | No comments
I’ll be talking about 5 Steps to Kanban at Software East on November 19th. From the website:
This event will take place at Red Gate Software, Newnham House, Cambridge Business Park. See the location map for Red Gate Software.
BOOK NOW for this event. Tickets (including light buffet) £15 if booked on or before 16th November, £25 [...]
October 9, 2009 - 1:06 pm
Tags: CFD, Cumulative, Diagram, Flow, Schedule, Workflow
Posted in Lean | 1 comment
Mary Poppendieck gave a talk on Workflow is Orthogonal to Schedule at Agile2009, during which she very neatly transitioned a schedule-focused view of work, into a flow-focussed view. At least I thought it was neat, so I’m going to try and reproduce the basic elements here, using my favourite agile workflow.
4 Week Time-box Schedule
Here we [...]
October 6, 2009 - 11:48 am
Tags: Conference, Kanban, KSE:London
Posted in Lean | 1 comment
I ended up making notes at the Lean & Kanban UK Conference with good old fashioned pen an paper. Rather than try and write up those notes into something coherent and meaningful, I have decided to write them up in the style of a twitter stream. These are the things I would have tweeted if [...]
September 25, 2009 - 8:43 am
Tags: Kanban, Practices, XP
Posted in Lean | 13 comments
During recent discussions with XP folks on the topic of Kanban, it occurred to me that based on my understanding, XP can be described in terms of a Kanban System for Software Development. This is an attempt to do that, on the basis that it might be useful in helping teams understand Kanban concepts. I [...]
I’m going to be at Agile 2009 next week in Chicago. I’m not presenting any sessions this year, but I’ll be hanging around the Kanban stand at the Freshers Fair, and probably spending some time in Open Jam to hopefully catch up with people in person while I have a chance.
I’m also really pleased to [...]
August 14, 2009 - 2:21 pm
Tags: FAQ, Iteration, Kanban
Posted in Lean | 2 comments
There has been some recent discussion on the blogoshpere and twitterverse about the relationship between Kanban Systems for Software Development and the concept of iteration. The often raised concern that a Kanban System is “Waterfall 2.0” came up again, along with the suggestion that a Lean perspective might view iteration as rework, and as a [...]
January 25, 2009 - 6:57 pm
It’s a good distinction you make. A way to make that idea clear (that stages are stages, not roles) is to say that Kanban can have one stage only (in process) if the teams already know what they can do to make it get to “Done”.
I agree with Marick when he says that exemplifying Kanban with “analysis -> Design -> Implementation -> Testing” leads people to confuse Kanban with Waterfall (which could not be further away from the truth!).
Don’t you get the feeling that the world is not ready yet for “Flow”? I constantly get that idea, every six months companies all over the world squander countless millions of people-hours in creating a fat list of objectives for the next 6 months. This clearly tells me that the world at large does not understand the simple idea of doing one thing at a time…
January 26, 2009 - 12:46 pm
I think this is one of Kanban’s strengths. Other Agile processes have “the team” and while they are all “equal” their identity is tied up with what they do, and generally people want to do the job their doing. This can create difficulty because people (mainly non-coders) can have difficulty seeing where they fit in on an Agile team. Its a lot easier for a Java coder to help out with testing than it is for a Tester to start coding Java.
So with Kanban people see a place for their roles, they see a BA activity, a coding activity and a test activity and see where they fit in. Yet as you say its not roles its stages, so over time people see where the problems and bottlenecks are and can choose to step out of role to help with the issue.
On day-1 I would not be overly concerned if people equate stages with roles, however if that mindset continues I would be concerned, then waterfall would be creeping in. Getting people to break out of their defined role and work on what is needed in part the responsibility of the Coach or Manager.
May 30, 2009 - 8:30 am
Hi I do understand the concept and I strongly believe that the idea of stages is a good idea in production near environments.
Maintenance or product delivery where you have a continuous flow of very small features to implement. I also believe it might make sense in big projects … the concern I do have is: there are not stages in creative work. F.e. Dev. and Test as a stage is in my eyes not really useful if you do Test driven development. I integration a separate thing? Yes — because people believe it is. But it is not. Integration should be part of development not a separate stage. Analysis the same.
It is very clear for me that a lot of people want to build a class of programmers. Not self-critical adults who enjoy going to work. And for this TPS is the best you can do — squeeze everything out of the workers and when they get old, replace them. (what they do in these cool japanese companies. capitalism rules.)
Is software development a production typ of thing or a more an art type of thing?
Maybe everybody and every context has to answer this question case by case.
My dogmatic point of view
the production type view leads into the wrong direction. Break through innovation needs something else than flow. It needs a flip, an “invention.”
The TPS was the source for Six Sigma, TOC and and and. All cool things and necessary. The industry in every area does now deliver more products with less defects than ever. We all want this — more more more —-
But … look into our economic crisis … we do not need improvement, we do not need more from the same, more variations from the same. We need innovation, we need Scrum-Teams facing the odds, running through problems, people who want to go on a mission, every sprint.
Product Development – the “new new development game” was something else than production.
I know there is a place for steady and contiuous delivery of more or less the same. Customization instead of innovation.
The only things is …. we should not confuse what was for what.
Scrum f.e. was for “controlling the chaos” — KANBAN might become the state of the art for controlling the production line in maintenance and minor enhancement environments.
May 30, 2009 - 7:41 pm
Boris,
Firstly, much of your description of the stages does not match my experience. I do not use dev, test and integration stages. I do have a stage for ‘backlog grooming’. Do your product backlog items appear in the right format instantly?
Secondly, kanban is more like the “New New Product Development Game” than Scrum. Overlapping stages with no time-boxes.
Finally, I recommend you read “Managing the Design Factory” by Don Reinertsen for an insight into Lean for Product Development (as opposed to Manufacturing)
Karl