Agile Fashion

So that we can easily find ways to constantly improve while collaborating effectively and sustainably, I like kanban as a tool which shows what constrains transforming concepts into cash. I believe it allows us to see the whole system and our part in what to do to help in the transformation of the system into a better one and our ideas in to innovation. It seems to me there would be greater benefits for all involved.

For software a kanban tool must be highly visible, with a policy to strictly limit work in progress and a policy to only accept work when there’s capacity. To be effective, it requires consensus on these policies from the people involved.

Kanban is a Lean way of saying, “I trust and respect you”.

After a few months working with a client, a WIP limit was introduced on story points at the latest planning meeting. When we started I said, “The good news is, you no longer need to track hours remaining. The better news is that you may never have to have this type of meeting again.” Here’s a nearly verbatim email from senior management, after planning.

We concluded the sprint planning today with a stack ranked backlog based on work folks did over the last couple of days (to get it prioritized). The sprint planning went well, all teams are “fully loaded” for the sprint except for Team-1. Here are my observations, anyone on this thread, please feel free to pitch in:

Team-1 was at ~(x) points, and the max per sprint is (y), so they could have taken more user stories. We went down the backlog and the next 6 or 7 required [special-skilled work only a couple people can do and they were] already maxed out (…) for this sprint. Further down the backlog were [feature groups for another team] related stories and since [those feature group] teams were max’ed out, we just stopped.

So, does this mean that Team-1, once done with their user stories, are going to start twiddling their thumbs? Maybe, but first, they HAVE to help other teams:

• with tasks
• with user stories
• help QA in testing to get the stories to the done state
• remove blockers from the blocker board (and we have identified new blockers that are slowing us down per the retrospectives)
• and basically help in any way shape or form move the stories on the board to the done state.

If all of the above is exhausted and there is really nothing else that Team-1 can do to help the current “in-flight” user stories across teams get to the done state, then, yes, they will be twiddling their thumbs and we would have identified a blocker that we need to address. Otherwise, we continue to push forward.

Do you think the new WIP constraint and attitude will help? Will there be an increase velocity and in quality of delivery, in your opinion? How about the effect on sustainable pace, or collaboration? Please comment below and I’ll provide my own opinions in following posts.

Available from Karl’s blog for download. The session went well, everybody returned for the second half from the first half. I really enjoyed the simulation at the end, although we ran out of time to fully go through it. If you happen to use it, would you contact us and let us know how it went?

As Karl Scotland noted, we will be presenting a session on Kanban, Flow and Cadence (KFC) at the Agile Conference this year. This will be Thursday 7 August from 8-10 and then 10:30 to noon in the Essex Ballroom as part of the Breaking Acts Stage.

This workshop explores three important Lean concepts – Kanban, Flow and Cadence (KFC) – which can be combined to generate a more pipeline-based approach to software development, as opposed to the more common timebox-based approaches of more traditional Agile methods. The presenters will describe their experiences implementing these ideas at Yahoo! and explain the concepts using examples, simulations and games. In addition, because this is a new and emerging way of working, there will be an opportunity for discussion between the participants about how the ideas might be applied in their own situations, in order to advance the art.

All you need is a pack of cards…

Ask people what kind of typical things happen to get a user story from the backlog to in the hands of users. Agree on the most common 3-5 things, such as: exemplify/design/build, or story/TDD/accept/deploy, or the typical todo/wip/done or the traditional analysis/build/validate/deploy Group people by this same number at a table. The grouping of will make more sense in next exercise.

As prep for the next exercise, also count out 4 aces, three twos, two threes, one four and one five. Set aside from the 20 used here.

Maximize what is done
The example shown involves groups who went traditional with the value stream of 4 and 20 cards per group. Best to use a deck per group, with those other cards set aside.

Start timer
person 1 to flip all 20, pushes to output area. Person2 flips them all, pushes to output area.
Person 3 flips them all, pushes to output area. Person4 flips them all. Stop timer.

While all are in progress, ask how many items are in progress.

Debrief. How much is in progress (20) how much wait time? How long did it take to get done?

Do again, but this time 1 card at a time, in parallel
Remember to ask how how many things are in flight, once all 4 people are flipping cards.
Stop timer
Debrief. How much is in progress (4) how much wait time? How long did it take to get done?

Pull Work Through
Did you set aside the cards from the last game? If not, count out 4 aces, three twos, two threes, one four and one five.
Turn one face up for every two face down or so.
Still have the groups of 4? If not, re-form groups of 4. Call out again roles of analysis, build, validate, deploy. Redefine the output areas.
Responsibilities:
First person (analysis) makes sure they are all face down
Second person (build) makes sure all are face up
Third person (validate) flips them down and up to number on card. Flips the aces down and up, the twos down-up-down-up, etc.
Fourth person (deploy) groups by number
Two passes, TIME EACH!
First time a person works when the workspace is empty, and puts work in output queue as quickly as possible
Second time, work is done only when output queue is empty
Should take almost the same amount of time.

Lesson learned, go as fast as constraint.
How can we exploit constraint?

————–
Of course, there are other lessons to be learned, and variations that can be performed. I’m just trying to provide the basics here. This is a messy post and would be better explained through example. At some point, I’ll video these and post here, too.

For me, it’s all about getting the backlogs together and putting strict limits on WIP. It is a mess to find a bottleneck, or get to done, when too many things are in flight. Remember: there is one expedite slot to override WIP, but only one.

Two ways to limit WIP:

1. With the value stream mapped, look at the resources within a certain step and ensure there are no more slots than people in that step.
2. If there is an inability to get the value stream map, or while you’re going there, write a sticky for the name of each developer
   1. With all the things in flight, have a person put their sticky name on the WIP
   2. Have them move their name to whatever they are working on
   3. Don’t allow more things to be allowed in to WIP until there is no way they can put their name on something
   4. Only allow for one WIP per person
   5. Cut the WIP slots in 1/2 for pairing

If you’re trying to enforce pair-programming, or otherwise get cross-functional and more collaborative teams, limit WIP to half the number of developers. There should be a minimum of 2 slots for any one step in the process.

In throttling down in this way, and trying to get a handle on what’s in flight, make this request:

Put your name on what you’re working on
Nothing to work on? Ask if you can help someone else.
Don’t have the right skills for that? Find the bottleneck and work to release it.
Don’t have the right skills for that? Pull in work from the fixed queue.
Don’t have the right skills for starting anything in the queue? Ask the PO if there is anything lower priority to work on.
They don’t have anything? Go find other interesting work.

A lot of popular folks come to Yahoo! and hang out. There are experts, authors, musicians, luminaries, – giving talks, running workshops, attending conferences, performing, and being a presence on the campus.

Our own group has had people in. I’m not sure who they all are. I hear there was Mary Poppendieck, who’s suggestion of eliminating waste may have been interpreted by a few as meaning some roles could be considered redundant. Seems a shame.

Since I’ve been around, there has been two people we’ve brought in. The first was Jim Coplien, who shook things up a bit. People are still referring to his presentation on agile architecture. We have it on video some where. I wonder if I can make it public? Worth finding out and better than me writing about it now.

Today David Anderson came in, and talked about industrial-strength, agile complimentary, product development system. This system is based in the Theory of Constraints (TOC), where customers pull value through the system. It takes advantage of mathematical fact and scientific backing in queuing theory and Little’s Law. The system is monitored real-time with an ever-changing visual board of all work in progress. Product is developed in a cadence, where success happens with enthusiasm. David calls it a Kanban System for Sustaining Engineering, and with a subtle change, it is a system for software engineering.

Slide Deck in the video

Recently on the kanbandev Yahoo! group, there were some messages going back and forth between Corey and David on the differences between a retrospective and an operations review.

I think it was decided that the decoupled Operations review is more of a presentation, where the retrospective is a focused discussion. Corey was relating the ops review as multi-team stand up in the large, and then it sounds as if the retrospective would be follow-up work for specific teams.

At any rate, here’s David’s explanation:
Anatomy of an Operations Review
Operations Review
Chapter 14 from Agile Management: Operations Review

With iterative software, we talk about doing all the necessary functions, such as Design, Develop, Inspect, and Release, within each cycle to increment the value of available software to the customer. Our team divides the things in progress in to these categories, and has a finite amount of slots available to each category.

Friday after the daily stand-up found me, the Product Owner (PO) and the Lead Developer discussing a constraint to work. The Design category is done with its work, but the ready slot for Development is full. The team cannot pull any work in to this area.

The Product Owner wants to give more work to the Designers. I point out this is a push and we really want to refrain from dispatching work out to individuals. Staying focused in on the Designer area, the PO wants to know why we cannot just add more ready slots for Design to put finished work in to, and allow more work to be pulled in. We discuss how the system is designed at limiting the amount of things in process, and this may not be the best idea.

Suggesting we pull back and look at the whole board, we noticed that it is Development that cannot pull more work in to their area, because they are completely filled up with work that is not finished. There is one gnarly task to fix all high-priority defects. It is a worthwhile goal, but perhaps too costly to try and battle them all.

The Lead Developer is watching our discussion and chimes in with something another senior developer has brought up before, batching up the top 5 and parking the rest. These are lower priority than other queued-up feature work. It is pointed out that really, not everybody is working at fixing defects as wanted. There is other work in progress in the Development area.

This is completely agreeable to the PO and so the work is now to enumerate those top 5, which will also help with the Inspection and Release areas to deal with a manageable batch size, too. Soon this should relieve the constraint and allow Development to pull in the Design ready work, freeing Design to concentrate on pulling in new features to work on.

It was so easy then to point out local optimization. Now with some humor and looks relieved of their tension we can chuckle about optimizing one person in Design, instead of dealing with what is really slowing things down at the moment. We part ways with a better understanding of what is going on. Happy to help in making an improvement, we know throughput will soon be on the rise.

A little while ago I received the following email:

Dear agile bloggers,

Your recent blog post, reference or article has been referenced in the latest Carnival of Agilists – the blogroll pointing you to some of the latest thoughts in the agile community. The carnival is a biweekly blog posting rotated through the agile community to point others seeking to learn more through agile practitioners.

The source for the carnival posting this week is at http://trailridgeconsulting.com/blog/?p=99

It is also referenced at the Agile Alliance Carnival located at http://www.agilealliance.org/show/1670

Thanks for your contributions and feel free to spread the word through additional references. If you would like other recent works referenced, want to recognize someone else’s work, or you would like to host the carnival sometime, please respond to this email address (agilists.carnival@gmail.com).

Pete Behrens
pete@trailridgeconsulting.com
One of Many Carnival Hosts