Kanban System for Software Engineering
Introduction
Kanban (in kanji 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:
- 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.
- Resisting the temptation to add more work after an MMF is already in progress, or add more slots when the system is full.
- Being willing to make hard choices during a planning meeting.
- 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
- Median Cycle Time
- Throughput = TIP/cycle time
- Daily count of P1 and P2 bugs not resolved
- 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, 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
