James Shore: Successful Software

Highlighted by yyeret

on 2009-01-27 by yyeret

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.

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

Highlighted by yyeret

A small backlog is good because it limits the amount of time an MMF can wait, which prevents them from getting stale.

Highlighted by yyeret

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

Highlighted by yyeret

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.

Highlighted by yyeret

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.

Highlighted by yyeret

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.

Highlighted by yyeret

If the "Urgent" slot is full and another urgent item appears, it has to be added to the backlog queue

Highlighted by yyeret

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.

Highlighted by yyeret

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.

Highlighted by juhariis

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.

Highlighted by yyeret

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.

Highlighted by yyeret

But the ideal is still one-piece flow: working on just one item at a time, with no inventory waiting

Highlighted by juhariis

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

Highlighted by yyeret

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.

Highlighted by juhariis

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.

Highlighted by jmbeas

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.

Highlighted by yyeret

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.

Highlighted by jmbeas

f you're producing a new product or a significant new release of an existing product, use iterations

Highlighted by yyeret

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

Highlighted by juhariis

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

Highlighted by yyeret

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.

Highlighted by jmbeas

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.

Highlighted by jmbeas

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.

Highlighted by juhariis

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.

Highlighted by juhariis

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)

Highlighted by yyeret

So, should your team use iterations or a Kanban system? Here's my criteria:

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.

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.

Highlighted by juhariis

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.

Highlighted by yyeret

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.

Highlighted by yyeret

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.

Highlighted by yyeret

Popularity Report

Total Popularity Score: 0

Rank

URL Tag Cloud

Groups (0)

Related Lists

Bookmark History

Public Comment

Public Sticky notes

on 2009-01-27 by yyeret

Site Community

Readers (6)