Changes between Version 3 and Version 4 of SoftwareEngineering/KanbanInAction


Ignore:
Timestamp:
Apr 30, 2018, 2:07:39 PM (6 years ago)
Author:
Vijay Varadan
Comment:

Ch07 notes

Legend:

Unmodified
Added
Removed
Modified
  • SoftwareEngineering/KanbanInAction

    v3 v4  
    6767
    6868=== Limiting WIP
     69> **The question is, are you selling keystrokes or completed features?**
     70
    6971* There’s no one right WIP limit for you and your team.
    7072* Limiting WIP isn’t the goal; improving flow is. WIP limits are merely a tool that helps find problems that hinder a better flow.
     
    8688
    8789=== Managing Flow
     90* Flow (or continuous flow) is an ideal state that describes a process in which every step in the process creates value, with no interruptions or waiting time.
     91* Pursuing this ideal state is a never-ending quest that will help you not only get a smoother, faster flow but also find problems in your process.
     92* Everything that isn’t value in the eyes of the customer is waste. Eliminating waste leads to better flow.
     93* “Managing flow” is one of the principles of kanban, and there are a lot of things you can do to help the work flow:
     94  * Limit WIP.
     95  * Reduce waiting times in your process: for example, by ensuring that the work is always ready for the next step or by making the work items smaller so that they move faster through the process. Remove blockers as fast as possible. Or why not strive to “never be blocked”?
     96  * Avoid rework by building quality into your process from the start. How much of the demand you have in your system today is failure demand? How can you have less failure demand and more value demand?
     97  * Create cross-functional teams that can minimize waiting times.
     98  * Use goals and targets like SLAs to get clear timeboxes and objectives to strive toward.
     99* Many teams use the daily standup to collaborate well together. Here are some practices to help make a standup great:
     100  * Keep it short and energized: never more than 15 minutes (that’s why you stand up).
     101  * Keep it regular: same time and place every day.
     102  * Keep it disciplined: start and end on time.
     103  * Keep it focused: complete discussions afterward.
     104* Many kanban teams have some practices that they follow:
     105  * Focus on the work, not the workers.
     106  * Walk through the items on the board from right to left.
     107  * Focus on deviations—the smells in your process.
     108* Here are some other things to think about to get the most out of your standup:
     109  * Is all the work visible on the board?
     110  * Are we working on the right thing?
     111  * Do we understand the work?
     112  * Encourage spontaneous kaizen meetings after the standup in which small improvements are made every day.
     113* Standups can be scaled to more than one team, but make sure each layer adds value and isn’t just another reporting instance. Think about the following:
     114  * Run before or after smaller team standups?
     115  * Who attends?
     116  * What kinds of visualizations are needed?
     117  * How will statuses be synchronized between local team boards and other boards?
     118* "What should I be doing next?" is a common question at standups. With explicit policies on how to handle that question, you minimize the risk of hindering the flow of work.
     119* A bottleneck is something that slows down production. With queues, you can get leading indicators and discover the bottlenecks.
     120* The Theory of Constraints is a management theory built around finding and eliminating bottlenecks in a process.
     121
     122[[br]]
     123> An activity in itself isn’t a value-add or waste; it’s the **return of time invested (ROTI)** in that activity which determines if it’s waste or not.
     124
     125==== The Seven Wastes of Software Development
     126* Partially done work - Work that isn’t completely done is in reality just work in process. It lies around waiting for you to complete it and adds to your WIP.
     127* Extra features - Taiichi Ohno famously said, “There’s no greater waste than overproduction.” Build the right thing. On an individual level, if you’ve ever thought “This may come in handy” or “Maybe they want this to be configurable,” it's likely wasted.
     128* Relearning - Software development is, to a great extent, learning. Failing to remember mistakes you’ve made before and having to redo them (and relearn the solution) is a great waste. This can happen both in teams and for individuals.
     129* Hand-offs - When you hand work from one person to another, a lot of extra work is created in order to convey necessary information to the next person. Even with that extra work, a lot of information will be lost in the hand-off.
     130* Delays - Delays create extra work.
     131* Task switching - Context switching and the wasteful effect it can have on your focus and capacity can be as high as 10% per switch.
     132* Defects - Defects are work that comes back to you because you did something wrong the first time around. Not only does this create extra work, but typically that kind of work comes at a bad time, slowing down the things you’re working on right now.
     133[[br]]
     134> **Optimizing for flow vs. optimizing for resource utilization is a strategy decision.** Lean as an operations strategy aims to increase resource efficiency through focusing on increasing flow efficiency.
     135[[br]]
     136> **Specification by Example**: Write your specification in the form of acceptance criteria or concrete examples (real numbers and real data used) of how a feature will be used. The feature will be complete when the example is fulfilled: nothing more, nothing less.
     137[[br]]
     138> **Never be blocked**: Like a good pool player who always makes sure the shot he is taking sets up the next shot he expects to take, every step a good agile developer takes enables the next step. A good agile developer never takes a step that stops his progress, or the progress of others. - @unclebobmartin
     139
     140==== Five Focusing Steps
     1411. Identify the constraint of the system: for example, a single machine that all the parts in a factory need to pass through.
     1421. Exploit the constraint to get the most out of it. For example, make sure the machine is running all the time.
     1431. Subordinate all other work to support the exploitation of the constraint. For example, make sure you don’t send faulty parts to the machine; that would be a waste of time for the constraint.
     1441. Elevate the constraint. For example, buy another machine to share the workload.
     1451. Rinse and repeat. Go over your system again, and see if the constraint is still the biggest constraint in the system.
     146
     147=== Classes of Service
     148Assigning different classes of service to different work items is an easy way of creating a simple and transparent approach for the team to self-organize around the work and to meet the needs of the business by making work-item value, risk information, and policies explicit.
     149