I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

* reflect and honor the practitioners who make its existence possible;
* provide an excellent experience for its members;
* support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
* exemplify, as a body, the professional and humane behavior of its members;
* engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
* embrace newcomers to the community openly and to celebrate ongoing journeys; and
* thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders builders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders the community’s builders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A community of thinkers” by Liz Keogh, Eric Willeke and Jean Tabaka is licensed under a Creative Commons Attribution-Share Alike 3.0 License.

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 VYC2.0 launched, I was asked who were the heroes in the group. The one or two people who deserved recognition for all of their hard work. I was hunting around for the email chain, but I’m pretty diligent about deleting emails. I wish sometimes I wasn’t so relentless at that, but I don’t have it. Essentially, I responded that calling out a couple of people creates competition, that everyone stepped up and deserves to be recognized. Management agreed, and everyone involved wound up with a Flip, and I was asked how we may be able to codify some whole team incentive.

My answer was pretty short in coming, as I have wanted to establish the proposed incentive program written about in the ground rules for one team I was working with doing kanban stuff.

The following is what was agreed upon by our senior management. Some things were changed, and quite drastically. For starters, credit will only be given for features/stories completed in one Sprint. When asked my opinion, I suggested this may lead to technical debt. It was also decided to have a showdown at the end of the year, and to recognize the team with the most redeemed tokens. I am afraid this is against the whole-team incentive, and once again fosters competition.

Here it is:

“Video Tokens” rewards

Team collects tokens (1) for every MMF/story that is developed & tested in 1 sprint

Eligibility:

All Video Platform Teams

Selection criteria:

MMF/Story must meet acceptance criteria from Product Owner, must be tested and bug-free

Selection process:

At the end of each Sprint, Scrum Master will review Sprint deliverables and compliance w/ selection criteria. Tokens are awarded to a team.

Timelines:

End of each sprint

Rewards:

Finished features can be collected by the team and redeemed for rewards. Team can decide to either redeem their collected points or wait to accumulate more points for a higher reward

• 10 = Beer and snacks for the next Review & Retrospective
• 25 = Team Lunch
• 50 = Movie passes
• 100 = Day off

ALL tokens collected and/or redeemed are counted annually when team enters into Annual Token Standoff.

Program Facilitator

Scrum Master or Program Manager

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?

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.

When asked any question, just reply with something like the following. Or work it in to a conversation.

1. The team says, “look what we’ve done” when there is a good leader. A typical manager says, “look what I’ve done with this team”
2. QA is a platform
3. Prioritize features by risk and known market needs. Group them by goals and technical similarity.
4. What is the expected revenue from this feature?
5. It is easier to automate 10 lines of code at a time than 10,000 for builds and tests
6. Inspect and adapt requires looking at what’s going on before changing it
7. Software development is an adaptive system with emergent behavior
8. What is the degree of variance on that estimate?
9. Greater uncertainty lowers confidence in any estimate
10. How many things are currently in flight?
11. Self organization allows the team to do whatever is necessary to finish commitments
12. Increasing skills adds individual market value
13. Lines of communication must be open between all roles

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.