need to understand how it can work when there are multiple small teams eating up a single backlog of a single product (e.g. modules in the product). not an ideal agile team in any case, but stuck with one.
This link has been bookmarked by 21 people . It was first bookmarked on 16 Oct 2008, by Eddie Osh.
-
10 Apr 12
-
02 Mar 11
-
20 Apr 10
-
02 Mar 10
-
26 Feb 10
-
22 Jun 09
-
11 May 09
-
08 Apr 09
-
What Toyota was really trying to accomplish was "one-piece flow." One-piece flow means manufacturing items one at a time rather than in batches. It creates flexibility, improves productivity, eliminates waste, increases throughput, cuts time to market, reduces the impact of error, and reduces the cost of inventory. It's a Good Thing.
-
But the ideal is still one-piece flow: working on just one item at a time, with no inventory waiting
-
The challenge is to develop a learning organization that will find ways to reduce the number of kanban and thereby reduce and finally eliminate the inventory buffer... So kanban is something you strive to get rid of, not to be proud of.
-
That's why I prefer Arlo's approach to David Anderson's. By using the Extreme Programming approach of simultaneous phases, everyone on the team works on one MMF and gets it to done, then they work on the next. Work-in-progress inventory is reduced to the absolute, bare minimum: just one MMF. (Beat that, Toyota!) By doing this, we create flexibility, improve productivity, eliminate waste, increase throughput, and do all of the other wonderful things that one-piece flow gets you
-
The good thing about Kanban systems is that they really do a great job of eliminating waste. They eliminate iteration planning, they react extremely well to changing needs, and they work well in chaotic environments. The theory behind them is sound, and if you are a fan of Lean ideas, then using a Kanban system will seem like a no-brainer.
-
I'm also concerned that Kanban will be too advanced for teams new to Agile planning. One of the great things about iterations is that they're timeboxed. At the end of the week (or month), time's up! You're done. Many teams struggle with this. They have trouble getting to "done done" and the timebox helps them recognize and eventually fix the problem. Timeboxes also prevent scope creep and they also force important trade-off decisions to be made. Overall, they're an excellent tool for improving the team's self-discipline, and Kanban systems don't seem like they'll provide those benefits.
-
-
If your team is new to Agile planning, use iterations. Be super-disciplined about getting everything "done done" each iteration, using slack, and achieving a stable velocity so you can consistently make and meet iteration commitments. This will force your team to learn important lessons about how Agile works.
-
If you're producing a new product or a significant new release of an existing product, use iterations. Create a vision, do release planning, get a good product manager, and make sure he's heavily involved. Your goal is to create a compelling product with significant value, and you'll benefit from a gestalt view of the product and the predictability iterations provide.
-
If you're in an environment where the feature backlog is constantly in flux or hard to predict, particularly if you can release the software on a whim, try the Kanban system. Entrepreneurial environments, maintenance of mature products, and recent releases are all examples of environments with unpredictable backlogs. The Kanban system will convert that chaos into a smooth, constant flow.
So, should your team use iterations or a Kanban system? Here's my criteria:
And if none of these categories seem to fit, go ahead and give the Kanban approach a try. You'll learn something new and hopefully have fun doing it. There's a lot of potential here, and I don't think we've explored all of the options. Try it! Let us know how it works out.
-
-
-
16 Mar 09
-
27 Jan 09
-
Add Sticky Note
-
-
he team takes a story from the backlog, develops it, and ships it as soon as it is done. Then they take the next story from the backlog, develop it, and ship that story. Work is shipped as soon as it's ready, and the team only works on one story at a time.
That's the ideal, anyway. Approaches differ
-
A small backlog is good because it limits the amount of time an MMF can wait, which prevents them from getting stale.
-
David Anderson doesn't use simultaneous phases, so his MMF-equivalents have to travel through multiple stages: Engineering Ready Queue, Systems Analysis, Development, Build, Test, Release Ready, and In Production. This means that his team works on multiple MMFs at a time, which leads to a need for complex configuration management
-
The team brainstorms and tracks the tasks required to complete the current MMF only. As tasks are completed, they're removed from the board; as new tasks are discovered, they're added. When all the tasks are done, either the MMF is done or the team has forgotten something.
Once the MMF is done and the on-site customers have approved it, the software is released. The MMF is taken off the queue and development starts on the next MMF.
-
There's no estimating of tasks or MMFs in this approach. Instead, you use what Arlo calls "Disney Line Planning": "Your wait from this point will be XXX days." In other words, you measure the typical time it takes to complete an MMF, from start to finish, and extrapolate to various points in the queue. Since MMFs can vary in size, this is a rough projection, not a commitment.
-
If there's an emergency, a support request, or some other urgent need, there's an empty slot on the board marked "Urgent." The team can put an MMF in that slot at any time without having to go through the regular backlog queue. The team strives to finish urgent items quickly, and they try to keep the slot empty and available at all times.
-
If the "Urgent" slot is full and another urgent item appears, it has to be added to the backlog queue
-
As with other Agile approaches, the team is expected to fix bugs before the MMF is done. If bugs are found afterwards, the fixes are scheduled with a new MMF. If a bug needs to be fixed immediately, the team uses the "Urgent" slot.
-
The good thing about Kanban systems is that they really do a great job of eliminating waste. They eliminate iteration planning, they react extremely well to changing needs, and they work well in chaotic environments.
-
ne of the great things about iterations is that they're timeboxed. At the end of the week (or month), time's up! You're done. Many teams struggle with this. They have trouble getting to "done done" and the timebox helps them recognize and eventually fix the problem. Timeboxes also prevent scope creep and they also force important trade-off decisions to be made. Overall, they're an excellent tool for improving the team's self-discipline, and Kanban systems don't seem like they'll provide those benefits.
-
In the field, I've seen Kanban work best in chaotic environments where upcoming features don't have much in common. I don't think it's a coincidence that the initial examples of Kanban come from those sorts of environments. David Anderson's team was responding to change requests. Arlo Belshee's team worked in a start-up, where frequent, entrepreneurial shifts in direction are commonplace. One team I worked with used a Kanban system to respond to post-release change requests, but plans to switch back to iterations once they start planning their next release
-
f your team is new to Agile planning, use iterations. Be super-disciplined about getting everything "done done" each iteration, using slack, and achieving a stable velocity so you can consistently make and meet iteration commitments. This will force your team to learn important lessons about how Agile works.
-
f you're producing a new product or a significant new release of an existing product, use iterations
-
If you're in an environment where the feature backlog is constantly in flux or hard to predict, particularly if you can release the software on a whim, try the Kanban system. Entrepreneurial environments, maintenance of mature products, and recent releases are all examples of environments with unpredictable backlogs. The Kanban system will convert that chaos into a smooth, constant flow
-
think four factors contribute to the number of MMFs in flight:
1- The team size (larger -> increase MMFs in flight)
2- The size of the MMF (smaller -> increase MMFs)
3- The team's ability to work on the same feature concurrently (better -> reduce MMFs)
4- The granularity of the design (smaller classes -> reduce MMFs) -
One card per pair seems way too high, and indicates to me that there's lots of room for improvement with that team's engineering practices.
-
I work with Arlo. The idea of "everybody on one MMF" is a principle more than an iron rule. We try to work on the top MMF and, being programmers, divide it into "threads". When possible, we "swarm" the MMF. As often as not, though, we have more pairs than threads, so other tasks get pulled into the working area.
-
For me kanban is a different approach to change. I've given up asking teams to learn new behavior and to "transition" them to a new way of working via training and imposition of positional power. For me kanban is about mapping the value stream as it exists, putting a pull system constraint around it and making the workflow visually transparent and gathering data from which meaningful reports are generated.
-
-
10 Nov 08
-
I like the idea of Kanban systems, but I'm not sure they're appropriate for everyone. This might just be unfamiliarity: I have a lot more experience with the old-fashioned iteration-based approach.
-
The good thing about Kanban systems is that they really do a great job of eliminating waste. They eliminate iteration planning, they react extremely well to changing needs, and they work well in chaotic environments.
-
I'm also concerned that Kanban will be too advanced for teams new to Agile planning. One of the great things about iterations is that they're timeboxed.
-
They have trouble getting to "done done" and the timebox helps them recognize and eventually fix the problem. Timeboxes also prevent scope creep and they also force important trade-off decisions to be made. Overall, they're an excellent tool for improving the team's self-discipline, and Kanban systems don't seem like they'll provide those benefits.
-
-
05 Nov 08
-
24 Oct 08
Yeray DariasIn the last few years, Kanban Systems have become an increasingly hot topic in the Agile community, thanks in part to the Poppendiecks' wonderful introduction of Lean Manufacturing principles. Three people who have been working on Kanban systems in the Ag
-
17 Oct 08
-
16 Oct 08
Public Stiky Notes
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.