Changes between Version 2 and Version 3 of SoftwareEngineering/KanbanInAction

Apr 28, 2018, 4:25:15 PM (6 years ago)
Vijay Varadan

Notes till Ch06 added


  • SoftwareEngineering/KanbanInAction

    v2 v3  
    2121* TBD
     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.
     26=== Kanban Principles
     27Kanban 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.
     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.
     39=== Work Items
     41A 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
     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
     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.
     87=== Managing Flow