Arlo Belshee and Jim Shore had an interesting pair presentation on titled “Single Piece Flow in Kanban” at LSSC10. A more accurate (although inflammatory) name for the talk is “Enough Kanban! Use XP for Single-piece flow”. It is worth mentioning that the context of the discussion is new product development.  Not sure about team size – seemed manageable. So this may be suitable for this context.

The basic arguement is that we should consider the flow of customer value. This is real flow. Moving Kanban cards representing tasks may be motion and not actual flow of value. The solution is not something new but something we already know: eXtremeProgramming (XP).

One challenge that Taiichi Ohno encountered decades ago when introducing Single Piece Flow at Toyota is that there is often resistance from specialists. They are more comfortable just knowing one piece of equipment.

The same challenge exists today when we ask developers, testers and domain experts to work together to deliver value. If your environment can work this way (and some can’t very easily) there can be a big cycle time and business value win.

What’s wrong with some Kanban implementations? Some have too many hand-offs and WIP due to queues. So, if you are using Kanban, this is something to watch out for.

Arlo and Jim describe the software work-cell as a collocated, cross-functional team that swarm work to minimize WIP and handoffs.

Gone is the release plan and the product backlog (see diagram). Instead a vision (which was a mindmap) drives the just-in-time generation of MMF (minimum marketable features) that are queued in the “on-deck” area. MMF is generalized to mean anything of business value. It could be a product feature. It could be a demo for a tradeshow.

For in-progress work, the notion of a Detective’s Blackboard was introduced as a dynamic unstructured area where tasks and task generators could be added and removed organically depending on the nature of the MMF. The idea is that tasks will grow as work gets started and then start to collapse as progress is made and new tasks stop appearing. (Maybe around when the MMF is ~2/3 complete.) In the example provided, the team was large enough to support 2 MMFs. The video and slides are available on InfoQ.

What looks like an earlier version of this is on Jim’s blog. See also Arlo’s video on Naked Planning. A video with session slides + Audio are on Jim’s blog.

Very cool stuff.

The purpose of this post is to provide a shopping list for collocated teams that use Agile to create a Kanban or Scrumboard. This acts as a boundary object to create context and bind a team.

Standard Sticky Notes

Post-it Super Sticky 3″x3″ Yellow (12/pack) – Staples Item#: 562896

Post-it Super Sticky Notes, 3″ x 3″, Neon Colours, 5-Pack – Staples Item#: 562930

Post-it Recycled Notes in Pastel Colours. Grand and Toy Product code: 655-RP-A
Good for production Kanban. Not supersticky, but bright colours can be annoying.
Stock 1 per team

Post-it Super Sticky, Neon Colours 4″x6″ –  Staples Item#: 592836

Post-it Notes, 1-1/2″ x 2″, Neon Colours – Stapes Item#: 20071

Special Sticky Notes

Post-it Arrows 3×3 – Staples Item#: 500518

Post-it Flowers 3×3 – Staples Item#: 573400

Post-it Super Sticky Notes, 4″ x 4″, Lined, Ultra Colours – Staples Item#: 659725

Post-it Super Sticky Meeting Notes, 8″ x 6″, Lined, Neon Colours

Markers & Etc.

Black Sharpies (12/pack) – Staples Item#:11520 – Also available in 24 count from Costco
These are critical to keep in good supply to keep people running to look for markers.
Stock 1 box per team

Bic Fine Tip Assorted Marker (12/pack) – Staples Item#: 573126
You’ll need these for size estimates, theming story cards
Stock 1 box per team

Post-it Glue Stick – Staples Item#: 18842
Useful for sticking stuff to the wall. Critical for index/story cards
Stock 2 per team

Index Cards, 3″ x 5″, White, Ruled - Staples Item#: 570562
Really stupid, but you can’t order Post-it index cards in Canada, so we need these for story cards. Yes, you can use coloured stickies, but these are more substantial and allow theming with coloured markers.
Stock 1 per team

Easel Pads

25 Inch Post-it Easel Pad –  Staples Item#: 22908

Other stuff

Painter’s Mate Green Painter’s Tape Contractor Pack – 6 pack @ Home Depot
Needed to demarcate swim lanes for scrum boards; phases in a story map; kanban columns
Stock 0.5 per team

Scotch-Blue Painter’s Tape for Multi Surfaces 25.4 mm x 45.7 m Contractor Pack (3 Rolls) @ Home Depot
Same as above but green. Choice is good.
Stock 0.5 per team

Work Samples

In the absence of high-quality magnetic whiteboards, I tend to use a lot of paper and stickies. So please see others for using whiteboards.  e.g. Visual Management Blog

On Saturday, the Toronto Agile Software Development Community had it’s inaugural Open Space event called Agile Open Toronto. It went really well. Lot’s of positive feedback and of course tips for improving next time. Sessions will be posted by conveners here (posts are starting to appear).

The purpose of this post is to share how the event was run for attendees and other Open Space enthusiasts.

Setting up the Space

As a not-for-profit, the City of Toronto provided us with a great space for free.  You can see us setting up below.

Empty Board

Rather than follow the suggested approach of an unstructured bulletin board, we elected to create a grid. Why? We find techies get really frustrated and will sort sessions by time anyway. Note that some of the session slots are marked reserved and only get opened up once there are enough sessions to run all day.

Lawrence Welcomes Everyone

Long-time host of XPToronto/Agile meetings opened the space.

Michael and Gino Pair Facilitate

We pair program, we pair test, we pair coach. We really like working together since it provides variety for listeners and it’s easier to remember everything between the two of us. As you can see, we are walking in a circle to set the tone and explain how open space works.

The Initial Rush

Once the call to action is given, there is a rush of motion and energy as people write session proposals.

The Board at the end of the day

Here’s what the board looked like at the end of the day. You can click on it to see a hi-res version and read the session titles.

Many thanks to all the volunteers: Edwin, Farooq, Tom, Bob, Micrea and others who arrived early and helped out. (If I forgot you, remind me and I’ll add your name)

Derek Longmuir presented ThoughtWorks QTB on working with legacy systems. You can see the video and slides on InfoQ.

I like the definition given by Michael Feathers:

Legacy code is simply code without tests.

Legacy Systems have Value. They are usually business critical and feature rich. They may even be stable and reliable (YMMV). Hint: in the MindMap below, start at 3 o’clock and go clockwise.

Why change from a legacy system? There are number of good reasons: obsolete technology, can’t add features, system is fragile.

This is an important problem since most systems we have 10% of the effort to build and 90% effort to maintain. So to manage costs, we need maintainable systems.

What to do?  Traditional approaches such as Big Bang (think explosion) and wrapping/hiding legacy systems rarely achieve business objectives.

Do a system health check. Look at the code. Get complexity measures. Look at test code ratio. What state is the system in?

Before getting started, there are some tools that you will need for basic technical hygiene. The equivalent of brushing and flossing your teeth is test and build automation.

How to tackle this?

With the Strangler approach, the goal is to strangle the existing application by building a new system that runs in parallel. The idea is to put a new interface in place and begin migrating the functionality in a piecewise fashion. This approach takes a lot of effort and makes sense when there is no hope for the existing code base.

The Phased approach is about rehabilitating the system piece by piece. How do you eat an elephant? One bite at a time.

Strangely, there was no mention of the bible on this topic: Working Effectively with Legacy Code by Michael Feathers. This book is a must-read on this topic. As is Refactoring, Refactoring to Patterns, and Clean Code.