Changes between Version 4 and Version 5 of SoftwareEngineering/KanbanInAction

May 1, 2018, 3:28:34 PM (6 years ago)
Vijay Varadan

Ch09 notes


  • SoftwareEngineering/KanbanInAction

    v4 v5  
    6868=== Limiting WIP
    69 > **The question is, are you selling keystrokes or completed features?**
    7169* There’s no one right WIP limit for you and your team.
    7270* Limiting WIP isn’t the goal; improving flow is. WIP limits are merely a tool that helps find problems that hinder a better flow.
    8684  * This can help you prevent too much multitasking and people being involved in every item on the board.
    8785* Most teams have a WIP limit on the work-item level, not the task level.
     87> **The question is, are you selling keystrokes or completed features?**
    8989=== Managing Flow
    110110  * Are we working on the right thing?
    111111  * Do we understand the work?
    112   * Encourage spontaneous kaizen meetings after the standup in which small improvements are made every day.
     112  * Encourage spontaneous ''kaizen'' meetings after the standup in which small improvements are made every day.
    113113* 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:
    114114  * Run before or after smaller team standups?
    120120* The Theory of Constraints is a management theory built around finding and eliminating bottlenecks in a process.
    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.
    125122==== The Seven Wastes of Software Development
    126123* 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.
    131128* Task switching - Context switching and the wasteful effect it can have on your focus and capacity can be as high as 10% per switch.
    132129* 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.
     131> 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.
    134133> **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.
    147146=== Classes of Service
    148 Assigning 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.
     147* Classes of service are a powerful way to make your policies explicit around the service level for certain type of work.
     148* Assigning a class of service to a work item can influence the work item: visualization, prioritization, impact on WIP, and workflow.
     149* Classes of service help the team to self-organize around
     150  * Work selection and scheduling
     151  * Work distribution
     152  * Making sure the work capacity is distributed as decided
     153* Common classes include
     154  * Urgent (or Expedite) - Prioritized over other work
     155  * Fixed Delivery Date - Needs to be completed on or before a certain date
     156  * Regular - Normal items, increasingly urgent, pulled FIFO-style
     157  * Defects - Rework produced by bad quality (you want as few of these as possible)
     158  * Intangible - No tangible business value now, but later: paying off technical debt
     159* You should use classes that suit your needs and situation, using the examples in this chapter as inspiration. There’s no one right answer for everyone.
     161=== Planning and Estimating
     162* Find the right time to plan - not too early nor too late, just in time:
     163  * Order points are one way to run event-driven planning.
     164  * Planning more often involves stakeholders around you more and builds trust, but it can also be costly. You need to balance it so that you plan with the right frequency.
     165  * Using Disneyland wait times is a way of showing expected delivery times.
     166* Plans and estimates are often requested by others around you, extend the workflow upstream and downstream.
     167* Estimating in exact terms is much harder than giving relative estimates, so prefer doing relative estimates:
     168  * Story points and T-shirt sizes are two common ways of doing relative estimates.
     169* Estimation techniques:
     170  * A line of cards
     171  * Planning Poker
     172  * Goldilocks
     173* Cadence is the natural rhythm or heartbeat found in your process. In iteration based processes, there are natural cadences when iterations start and stop.
     174* With kanban you can have the cadences you see fit for activities: reviewing, planning, demonstration, and retrospectives. You don’t have to tie it to the flow of your work.
     175* Need for plans and estimates:
     176  * Teams that use kanban see the need for detailed plans decreasing with the tightening of feedback loops.
     177  * Customers don’t want plans and estimates; they want business capabilities.
     178  * Estimating and making plans is useful as long as you’re uncovering new information.
     179  * The #!NoEstimates movement talks about abandoning estimates altogether and finding effective ways to work without estimates.
     181==== Planning Poker
     1821. Have a domain expert explain the requirement in question to the team, to ensure that everyone understands what it’s all about.
     1831. Perform the following estimation rounds, and only continue to the next round if you aren’t in agreement of the size of the estimate:
     184  * Round 1—Conduct silent voting using cards. No discussion, but cast votes: on the count of three as described earlier, for example.
     185  * Round 2—Let people think for a minute or two before doing a new silent vote, still without discussion.
     186  * Round 3—Let the team members explain why they voted as they did, and then vote again.
     187  * If you’re still not in agreement, then park that story for a separate session, and continue with the next requirement.