| | 23 | == Notes |
| | 24 | **Disclaimer:** These are primarily written for my own future reference, but they may be useful to you, either to decide if you want to read / buy the book or as something to revisit. The information is not comprehensive, not in the least - so, please don't use it as a substitute for actually reading the book. As with all my content, some is verbatim from the original source, opinion may be interspersed & of course, YMMV. |
| | 25 | |
| | 26 | === Kanban Principles |
| | 27 | Kanban aims to make the work flow fast through the whole value chain, from idea or concept to software in production, delighting your customers. |
| | 28 | * **Visualize** your work and policies. |
| | 29 | * **Limit** the amount of work in progress. |
| | 30 | * **Control flow** of work. |
| | 31 | |
| | 32 | === Visualizing Your Work |
| | 33 | * Visualizing your work is ultimately about creating the transparency and information-sharing needed to understand how the work works and to collaborate effectively together. |
| | 34 | * The process of visualizing work means making information visible that previously wasn’t, making implicit knowledge and policies explicit, and, in doing so, resolving inconsistencies and conflicts that surface. |
| | 35 | * The kanban board is a great way to visualize your workflow and share information about priorities, who’s working on what, the progress of individual work items, and so on. |
| | 36 | * By using a big, visible board, the information radiates to everyone interested instead of being hidden in people’s brains or inaccessible tools. |
| | 37 | * Creating a kanban board is easy: you map the workflow of your work items - that is, the steps they typically go through in order to be completed—to columns you create on a whiteboard or a wall. |
| | 38 | |
| | 39 | === Work Items |
| | 40 | |
| | 41 | A work item should contain all the information the team needs to be able to know how to work with it. Of the following, pick and choose what fits your current needs and add features as needed: |
| | 42 | * A description—So you know what the work is about |
| | 43 | * An avatar or other marker—So you know who is working on the item |
| | 44 | * Deadlines and other important dates—So you know when you need to have the item done |
| | 45 | * Tracking IDs or other references to an external system—So you know where to find more information |
| | 46 | * Blockers—So you can pick out items that are blocked and therefore hindered from further progress |
| | 47 | * Type of work—So you know the type of work for each item, which is important so you can prioritize the work items against each other if needed |
| | 48 | * Progress indicators—So you know how much of the work you have done so far |
| | 49 | * Size—So you can see the differences in size and effort |
| | 50 | * Flow data, emotions, and other data accumulated during the flow through the board - So you know how the work behaved and how the team felt about it |
| | 51 | |
| | 52 | === Work in Process (WIP) |
| | 53 | * The more WIP, the longer the cycle time for each work item will be. You should limit the WIP to get faster flow and shorter lead times. |
| | 54 | * WIP can take many forms, and we looked at some common ones in software development: |
| | 55 | * Specifications that haven’t been implemented yet |
| | 56 | * Non-integrated code that “works on my computer” |
| | 57 | * Untested code, which may or may not live up to your standards |
| | 58 | * Code not in production, which sits and wait for the next release |
| | 59 | * Problems and bad things can follow from having a lot of WIP: |
| | 60 | * More context switching |
| | 61 | * Prolonged feedback loop, which in turn causes extra work for you |
| | 62 | * And we mentioned some ways that WIP can manifest itself: |
| | 63 | * Increased risk |
| | 64 | * More overhead |
| | 65 | * Lower quality |
| | 66 | * Less motivation |
| | 67 | |
| | 68 | === Limiting WIP |
| | 69 | * There’s no one right WIP limit for you and your team. |
| | 70 | * Limiting WIP isn’t the goal; improving flow is. WIP limits are merely a tool that helps find problems that hinder a better flow. |
| | 71 | * A lower WIP limit will move your work faster and also bring problems to your attention more quickly. You want a low WIP limit, but not too low. |
| | 72 | * When setting out to find a WIP limit, start simple—maybe as simple as the slogan “Stop starting, start finishing.” |
| | 73 | * You can limit the WIP for the whole team/workflow: |
| | 74 | * This approach can help you improve collaboration. |
| | 75 | * It helps you keep focus on finishing work items before taking on new ones. |
| | 76 | * You can limit WIP based on column: |
| | 77 | * This puts focus on flowing items through the workflow. |
| | 78 | * It can help to manage bottlenecks. |
| | 79 | * Maybe you already have a hunch about what you need to improve and can start limiting WIP for that column. |
| | 80 | * Work can also be limited by estimated size (story points, for example). |
| | 81 | * You can limit WIP based on people: |
| | 82 | * Limiting the number of avatars that can be in play is one way to easily accomplish this. |
| | 83 | * Using swim lanes is another. |
| | 84 | * This can help you prevent too much multitasking and people being involved in every item on the board. |
| | 85 | * Most teams have a WIP limit on the work-item level, not the task level. |
| | 86 | |
| | 87 | === Managing Flow |
