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

Kanban System for Software Engineering – KSSE

Introduction

Kanban (in kanji ?? also in katakana ????, where kan, ? / ??, means “visual,” and ban, ? / ??, means “card” or “board”) is a concept related to lean and just-in-time (JIT) production. Kanban is a signaling system. As its name suggests, Kanban historically uses cards to signal the need for an item.

Kanban is a pull system that determines the supply, or production, according to the actual demand of the customers. In contexts where demand is difficult to forecast the best one can do is to quickly respond to observed demand. This is exactly what a kanban system does, it acts as a demand signal which immediately propagates through the entire chain.

Definitions

Cycle Time

The difference between the date any one thing is placed in the PO queue and the date that thing is released in to production.

Median Cycle Time

Cycle time in days within two derivations. “Your average wait from this point is between <x> and <y> days.”

Touch time

Amount of time spent working on any one thing.

Thing

Anything on the board which signifies something someone is working on. (bug/feature/enhancement/maintenance/etc)

Things-in-process (TIP)

Total of all things in each queue, except for the PO.

Minimal Marketable Feature (MMF)

AKA User Story. A feature that is minimal because if it was any smaller, it would not be marketable. It is marketable because when released in to production, people would use the feature.

User Story

They are written in the format of: as a <user> I want to <perform an action> so that I can <get some benefit>. Can use INVEST to also test if it is an MMF. Before it becomes TIP, the team agrees upon what the Acceptance Criteria are.

Acceptance Criteria

The constraints and conformance of a User Story. Agreed upon parameters that when met, helps ensure this feature conforms to the customer requirements.

Throughput

TIP/cycle time

Slot

Any one position in any queue. There are currently 5 slots in the PO queue.

Roles

Product Owner

A single person which must have final authority representing the customer’s interest in backlog prioritization and requirements questions. As the customer proxy, this person must be available to the team at any time. Responsible for understanding all the business rules for features. Whenever the team is unsure which way to implement a business decision, this is the person to go to first to make that decision of how best to enforce the business decision. Not responsible for any implementation work. The person with whom to check Acceptance Criteria with before MMF TIP leaves a station.

Challenges of being a product owner:

1. Resisting the temptation to “manage” the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself.
2. Resisting the temptation to add more work after an MMF is already in progress, or add more slots when the system is full.
3. Being willing to make hard choices during a planning meeting.
4. Balancing the interests of competing stakeholders.

Scrum Master

Responsible for removing constraints within the process. Identifies and removes any blocks from the team’s ability to work. Enforces the rules of the process and those the team has agreed to. Resolves conflicts; facilitates team decision making and problem analysis when necessary. Protects the team from outside influences and from attending any unnecessary meetings.

Product Developer

Anyone responsible for TIP.

Acronyms

• MMF Minimal Marketable Feature
• CM Configuration Management
• PO Product Owner
• TIP Things in process
• INVEST Independent, Negotiable, Valuable, Estimable, Small, Testable

Metrics

1. Median Cycle Time
2. Throughput = TIP/cycle time
3. Daily count of P1 and P2 bugs not resolved
4. Daily count of bugs not verified

Queue sizes

Queue sizes are subjectively derived based upon team size, and Median cycle time. Each queue, except the PO, has one slot for signaling a thing is finished and ready to be pulled in to another queue. Each one also has an expedite slot.

• PO = 5 for tip
• UED/Markup = 2
• ENG = 4
• QA = 2
• CM = 1

There is one ready slot for the UED, ENG and QA queues to signal this TIP is ready to be pulled in to another queue.

Process

Getting Things into TIP and on through to production

In the PO queue, the PO can rearrange what things are in which slot, and remove or add anything to any available slot. When some thing is placed in the PO queue, the team agrees upon the Acceptance Criteria. The date it is placed in the PO queue is recorded. At the bottom of the PO queue we’ll keep written the median cycle time. If something is an MMF placed in the PO queue, the PO has already determined that it is minimal.

Work is not assigned to people, the team accepts work into the next available slot in to the queue when they are ready to work on it.

When a slot is open and ready for some thing, it can only be pulled in to an available slot, based on which queue the team agrees it should go in to first/next. When work on the thing is finished for that queue, it goes in to the ready slot for someone in the next queue to pull it into an available slot in their queue.

Self-organization

Get Things Done

Work is not assigned to people. Work is not dispatched to someone who seems to be waiting and unsure. The Product Developers are committed to understanding what it takes to both engage in and accomplish finishing off TIP, as this is the product’s most urgent needs.

Releasing Constraints

At times, the system will slow down, or even come to a screeching halt. When this happens, Product Developers who are blocked on moving TIP and feel it is within their ability will engage in helping free up whatever is blocking their progress.

Other Interesting Work

Sometimes when the system slows, people will not have the ability to help release the constraint. When this happens, Product Developers are trusted to find other interesting work. This work could be in Career Development, Product Innovation, development process improvements, defect reduction or anything else the Product Developer finds to be interesting. The only requirement is that it is work that can immediately be put down when the system speeds up and moving TIP within the Product Developer’s responsibility is once again possible.

Kaizen

Kaizen(改 å–„, Japanese for “change for the better” or “improvement”; the English translation is “continuous improvement” or “continual improvement”).

Kaizen is a daily activity whose purpose goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work (both mental and physical), and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes.

Generating and Verifying Acceptance Criteria

Whenever the PO places a new MMF card on the board, the team then decides what its acceptance criteria are. These are recorded and kept with the MMF. Before any feature can be placed in a queue’s ready slot, it must meet all the acceptance criteria.

Stand-up

This daily meeting will still happen at its scheduled time. The team will be asked if the board accurately reflects what is being worked upon. The team will be asked if there is anything that is slowing down or stopping throughput. After these two questions are answered by the team, the stand-up is over.

Measures of Success

• Increase in throughput
• Decrease in cycle time
• TIP does not include defects

Visual tracking

• TIP signal board
• Average wait time for TIP to get to production
• Weekly throughput
• Bugs not resolved
• Bugs not verified
• Completed TIP

Tradeshow For Finished Features

Anyone may attend, and walk around the booths and check out what features have been released since the last tradeshow. This has typically been called the Sprint Review. This is to celebrate success of working software in production. People may wander through the area, getting demonstrations from the Product Developers responsible, at their workstations. Viewing the accomplishments will be other team members, stakeholders, Mashers, and anyone else who cares to look at the great things being produced by the team.

Retrospective

After every second(?) tradeshow, the team will analyze this process and determine if improvements need to be made. Operations may be reviewed, as well as teamwork, and the product development process.

Regular Cadence

Between recording the cycle time and overall throughput, the team will know at what regular rate features make their way in to production. This will help to drive how often to have the tradeshows, and what can be planned for a set time, such as a month, or a quarter.

Whole Team Incentives

Finished features can be collected by the team and redeemed for rewards.

example:

• 10 = Beer for the next Tradeshow
• 25 = Lunch
• 50 = Movie passes
• 100 = Day off

Introduction

On September 25th I facilitated a Product-level retrospective. The purpose of this retrospective was to look back at how user stories find their way to production, and to find ways to shorten the process and increase quality.

The format of the retrospective was taken directly from the book Agile Retrospectives. This style can be used on iteration/release/product cycles. It breaks the meeting down in to 5 components: Set the Stage, Gather Data, Generate Insights, Decide What To Do, and Closing. There are many activities which can be used to help with each phase. Choosing the correct activities becomes much easier when you know what the goal of the retrospective is; putting all the pieces together and to reign back in discussion if it veers too far off topic.

Goal

Understand a typical user story’s journey from conception to production, so that we may discover ways to shorten the trip, while improving quality.

Set the Stage

Because it was going to be such a long meeting, to set the stage we ran the “ESVP” activity. Each person is asked to rate their self as either an Explorer(eager to discover), Shopper(browsing and hoping to get at least one good idea), Vacationer (checked out but glad not to be working) or Prisoner (forced to come) for being at the retrospective. We had a good mix between Shoppers and Explorers, with only one Prisoner. I forgot to mention at the break that coming back was voluntary and if that person so chose to return, was no longer forced to attend. When asked if there was anything in this data that suggests how the team feels about work in general, the answer (besides it only told us how we feel about the retro) was that the team is cautiously optimistic.

Gather Data

We did a value stream (process engineering) mapping exercise to look at how many steps a story goes through, how long it is worked on versus how long it waits. This was done in teams of four, each choosing their own story to map. The idea was to map out the most typical flow based on these instances to find the longest amount of waiting and discuss ways to shorten that, or to find steps that could be eliminated/refactored for efficiency. This was too much work for the retrospective and something that will happen as time goes on. We were able to discuss the various maps drawn and it helped when we looked at deciding what to do.

An attempt was made to take one of the stories and try and break it down in to smaller sizes that would still deliver customer value. The idea was to look at what could be considered a Minimal Marketable Feature, in as much that it is minimal because any smaller and it would not be marketable. This also did not happen, but will probably be an effort that we can immediately implement and came up in an action of what the team can do.

A short exercise was then run to demonstrate how limiting Work In Progress (WIP) can increase throughput. In the teams of four, 20 cards are given to one person and that person flips over all 20 and then hands them (pushes) to the next person, who flips them all, and so on around to the last person. Average time was around a minute to get each person to flip all the cards. At most times, there are 20 ‘things’ in process at any slice in time, with most people waiting to do their work. The exercise was run again, this time with the first person flipping a card, and then allowing the next person to ‘pull’ the card in to their area and flip it. At any one time there are 4 things in process, and the average time for everyone to flip them all was under 30 seconds.

Lastly, the questions were asked how many things were in process on the team, what the size of them are and if they have value to the customer. The answers were that around 70-100 things are in process at any one time, of highly varying size and all of them have value to the customer.

Generating Insights

We used the Force Field Analysis activity to look at Ways to limit the work in progress, and for shortening the value stream. The teams of 4 discussed what would support the idea, and also what may inhibit the idea. After this the whole team shouted out answers, while I wrote them on a huge sticky. Ideas were enforced by darkening lines underneath with arrows pointing to the middle. The big supporters for Limit WIP were: Don’t go straight to ENG for stuff, swarm on a smaller amount of features, include QA, have visual tracking. Inhibitors were: Too much process, too much switching, and high-severity production issues. For the Value Stream, the supporters were: Limit WIP and break features into MMFs. Inhibitors were: external dependencies and tech lead unavailable due to meetings.

Decide What to Do

Even I was reaching my saturation point by this time, and the activity planned of Circle of Questions seemed out of context. I tried to just blow by it (bad) and someone called me out to go through the list and pull out specific things to do. The team decided that visual tracking, formalizing hand-offs, breaking features in to MMF and swarming of fewer things would be the best things to do. The next question, naturally was how to do this, which I didn’t want to get in to straight away but wanted to answer questions. I should have stuck to my guns and put off answering until the next meeting as it was getting late and you could feel the low energy in the room. There was a healthy discussion about getting developers to run tests before checking in and I suggested a quick workshop/walk through, which was canned.

Closing

The activity planned for this phase was the Return on Time Invested (ROTI) where people vote on a scale of 0 to 4 as far as benefit received to time spent. We didn’t actually vote like that, instead going for a thumbs up/down vote. Almost everybody was at thumb sideways. For the thumbs-down people, it was asked what was needed hat they didn’t get. Keeping the language simple and not speaking in agile mumbo jumbo was called out, as well as getting to the point quicker. Less exercises, only doing 1/2hour weekly retros were also listed. I also wanted to ask those thumb sideways to up what the benefit was, but we didn’t get that far. Overall, I would agree and grade myself about a B-/C+ on the effort.

Next Steps

1. Work with product to break features in to minimal, marketable chunks.
2. Value stream analysis
   1. Look for largest amount of waste
   2. Look for unnecessary process
3. Enable engineers to run the test suites and habituate the process

While attending Agile2007 I kept finding myself in the company of Arlo Belshee, especially as he was going through his implementation of a Kanban System at BlueTech LLC. The conversations became for me one of the stand out ideas discussed at the conference.

This process might have started when Arlo really got in to the lean literature and looked around for waste in the Scrum system. He believed he found it in estimation. The amount estimated to work always differs from actual amount worked, is therefore supposition and only a guess, so this estimation was declared muda. There are a few different references on the matter, including Dave Anderson, Mary Poppendieck, or Amit Rathore. Even NetObjectives weighs in with a course offering.

The idea of the variable length Product Backlog with the need to reorganize priorities and estimate size was replaced with a fixed-length queue placed on a whiteboard for the Product Owner (Customer) to fill with Minimal Marketable Features (MMF), or what in Scrum would be User Stories. The length of the queue is seven, as this is believed by Arlo to be about the maximum amount of items any one person can hold in their head at a time. The slots are marked with permanent marker. Since the Product Owner trusts the team to do the work, the team believes these features to truly be: minimal, as anything less would not be marketable, which has immediate value for new or existing users.

The customer is allowed to rearrange these 7 MMFs as often as is seen fit. When the team is ready to pull a new feature, it is whatever is currently at the top of the stack. The 7 MMFs must fit to one of two goals on the board. When entering a new feature, the customer determines if the completion of remaining MMFs in the queue would satisfy the goal. If so, a new goal can be added to the board and if not, another MMF to satisfy the goal is added. There is one expedite slot for the customer to override WIP, anything else has to wait for a slot to open.

Releases can occur any time any one MMF is finished, as there is an ability to hide Work In Progress on the production site. The customer also has an idea parking lot for the overflow from these 7 items, or for other goals. An approximate wait time of when a feature may be released is added to the bottom of the board. MMFs are dated when they are placed on the board, and when they are finished to derive the average time of a feature. Significant changes in the size of work which effects throughput trigger a recalculation of this lead time. Arlo calls it the “approximate Disneyland wait time”, and is a statement such as, “Your expected wait time today from this point is between x and y days.”

The engineering team has 4 slots for WIP. This was determined because there are 8 engineers who pair all code. A majority of the board is reserved for information related to the work. This could be an article on competitive analysis, CRC cards, an individual engineers task list, or anything else deemed interesting to the work at hand. Stand-ups happen multiple times per day and are short. When the team switches pairs they ask if there’s any significant increase of information of note which is not on the board.

The amount of information for a task crescendos and then as it starts to taper the customer is asked if this meets expectations. Sometimes the information arrival increases again after that, but then the information stops coming in and all tasks are complete and the customer is reviewing the MMF on the production machine. Every Friday is a trade show of all released MMFs, and is a very jovial time in the office, a celebration of a job well-done.