Kanban Systems for Software Engineering

Transcription

1 ScrumSense Cape Town February Kanban Systems for Software Engineering David J. Anderson Independent Management Consultant

2 Yahoo! Groups: kanbandev

3 April 21-23, atlanta.leanssc.org

4

5 Taiichi Ohno TPS = JIT + Deming Kanban is the tool that enables these

6

7 Kanban is a hot topic in the Agile community Open Space at Agile 2007 attracted 25 people Yahoo! Group now has members and growing Implementations at countless companies since August 2007 and on 5 continents BBC is best known adopter with more than 20 teams in London using kanban Other adopters include Software Engineering Professionals (Indianapolis), BNP Parisbas (London), IPC Media (London), and Robert Bosch Corey Ladas published Scrumban, a book about adding Kanban to Scrum Henrik Kniberg & Matthias Skarin, Kanban and Scrum published in Winter/Spring Davd J. Anderson, Kanban: catalyzing Lean in your technology organization, due in Spring

8 Features Managing with Queues back in 2004 Device Management Ike II Cumulative Flow Avg Lead Time WIP Time Inventory Started Designed Coded Complete

9 Immediately focus on reducing waste through improved quality measured as defects per unit of valued work Reduce work in progress Donald Reinertsen s Advice Together these will always have an immediate impact Given the groundwork on tracking and cumulative flow, the elements are in place to implement a kanban system

10 With Don s advice I developed my Recipe for Success Focus on Quality Reduce Work-in-Progress, Release Often Balance Demand against Throughput Prioritize And for advanced credit Reduce variability and improve the process

11 What is a kanban (pull) system?

12 5 Core Properties Definition of Kanban Limit Work-in-Progress Visualize Workflow Measure & Optimize Flow Make Process Policies Explicit Manage Quantitatively

13 Definition of Kanban (part 2) 5 Emergent Properties Prioritize Work by Cost of Delay Optimize Value with Classes of Service Spread Risk with Capacity Allocation Encourage Process Innovation Use Models * to Recognize Improvement Opportunities

14 Let s take a break for 15 minutes

15 Case Study Microsoft 2004/2005 XIT one of Microsoft s 8 IT departments XIT Sustained Engineering Small team Change requests Supports over 80 applications (and growing) Engineering responsibilities moved from Redmond (Washington, USA) to Hyderabad (India) in 2004 Hyderabad vendor is CMMI Level 5 and uses TSP/PSP Initial quality is very high

16 Change Requests Product Managers Change 70 Requests Sustained Engineering Supply v Demand Jan-04 PM Apr-04 Quarters Supply Backlog Demand Jul-04 Dev Mgr Supply Demand is outstripping supply and the queue is growing 155 Days Dark Days in July 2004 Test Mgr Manager resigns end June 2004 open position Q Backlog is 80+ and growing about 20 per quarter User Acceptance Test Lead time is 155 days Customer satisfaction lowest in IT department

17 Product Managers PM Mgr Change Requests3 Developers, Backlog Estimation (ROM) was Top Priority 3 Testers ROM But 80 Applications Estimation was using 33%-40% of available capacity!!! What happens? Days ROM Open and Read Source Code Read Application Guide Whole process about 1 day per developer and tester Test Mgr SLA 48 hours to return User a rough Acceptance order Test of magnitude estimate (ROM) All change requests are ROM estimated ROMs are expedited as top priority due to SLA

18 Budget Funding $600K* $200K $100K Estimates were used to facilitate cost accounting $100K Product Managers Change Requests PM Backlog ROM Dev Mgr 155 Days ROM Test Mgr Use ROM x Fixed Rate per hour to calculate Cost of Change Request Evaluate ROI of request ( Value/Cost ) Assign costs against bucket of funding from User Acceptance Test customer group *Numbers are indicative only

19 Product Managers Estimates were also used to facilitate monthly rescheduling Change Requests PM But Throughput was approximately 7 per month Backlog ROM Dev Mgr Backlog > 80 Rescheduling at least 70 requests that cannot be worked every month 155 Days ROM Test Mgr Monthly rescheduling meeting Assign urgency to each request on backlog Reschedule entire backlog based on urgency and ROM estimate (every month!) User Acceptance Test

20 Change Requests Actual effort was miniscule compared to lead time of 155 days Product Managers Change Requests PM Backlog ROM Historical data gathered over 9 months showed that a typical change request took approx 5 business days to process through development Low end was 1 day High end 15 days Dev Mgr 155 Days ROM Test Mgr to 2 3 to 5 6 to to 15 Effort in Days User Acceptance Test > 15 Dev Test

21 Product Managers Change Requests PM Backlog ROM Dev Mgr 155 Days Are Estimates waste? ROM Only 52% of requests were actually ever completed Other 48% Too big (bigger than 15 days) Too expensive (low value versus cost) Overtaken by events, application decommissioned before request is processed Test Mgr User Acceptance Test ROMs are taking 40% of capacity but 48% of ROMs represent analysis that is never used beyond estimate, schedule and go/no go decision! Knowledge work is perishable. ROM analysis is done months before work is conducted and there is no guarantee that ROM is conducted by same engineer who will code or test. Conclusion all ROMs are waste

22 Product Managers Change Requests PM Backlog Could it get worse? Expediting PTC Non-code Fix ROM Dev Mgr ROM Test Mgr User Acceptance Test Production Text Change E.g. 155 Days graphical changes, data changes, anything that didn t require a developer Must be expedited Need to make formal QA pass

23 State Model WIP limit initially 8 = 3 (dev) + 5 (q) WIP imit initially 8 = 3 (test) + 5 (q) XIT Change Request More Info Analysis New Info Received Transferred to Proj Team Pending Future Project By Design Duplicate Won t Fix No Repro Backlog Closed Approved On Hold Re-opened Dev Queue Dev Abandoned Started Resolved Failed Failed, Scope Changed Released Resolved (needs exception) New Started Test Queue Test UAT Queue UAT SOX On Hold Passed Started Complete Production Queue Passed

24 Change Requests PM Product from Test not Backlog Dev Managers PTC Expedite Kanban 8 cards (3 WIP 5 Queue) Development Kanban Typically enough for WIP + 7 days Test Kanban Typically enough for WIP + 7 days Pace line at rate of consumption Intervention 1 Pace the Line from Development Kanban 8 cards 25 Days Local Mgr User Acceptance Test At times of high expediting levels, kanban insures that line is paced Reduces lead time by insuring single-tasking Focuses customer acutely on selection of highest priority (urgency) requests for insertion into empty buffer slots

25 Product Managers Change Requests PM Stop cost accounting Kanban 8 cards (3 WIP 5 Queue) Intervention 2 Stop Estimating Kanban 8 cards No such thing as a cost of change request Costs are fixed PTC Expedite ROM activity abandoned Freed up 40% capacity Instant boost to productivity numbers Local Mgr Edge cases Funding Backlog is spent with vendor on 12 month 25 contract Days and paid out on monthly burn rate All changes would be treated equally for cost purposes Too big (take risk, identify once in development) Too expensive (don t care) Following Deming s advice manage for the normal and treat exceptions as exceptional Based on average of 5 business days through development User Acceptance Test

26 Product Managers Change Requests PM Backlog Intervention 3 - Balancing the Line PTC Expedite Kanban 9 cards (4 WIP 5 Queue) Kanban 8 cards 25 Days Local Mgr Kanban system and eradication of estimation should introduce slack in test Historical data suggested ratio of dev:test is 2:1 but XIT SE has 1:1 ratio (July 2004) Visited India to observe team after first two interventions Confirmed belief that test was not fully utilized Ask vendor to reallocate resource from test to dev to 4:2 Note: Change to kanban size for Dev Instant improvement in productivity (36 to 45) 25% User Acceptance Test

27 Change Requests Intervention 4 - Invest for Yet More Throughput PM PTC Expedite Kanban 11 9 cards (5 (4 WIP 65 Buffer) Kanban 8 cards Product Backlog 25 Days Managers Increase staff to 5:3 dev:test ratio in July 2005 Local Mgr Having eliminated waste and balanced the production process Removed ROM estimate waste Removed slack from test And changed policies that were causing muda to occur Ceased cost accounting removed ROM estimate waste Re-wrote SLAs with customer Changed prioritization and delayed commitment Total Improvement of 155% in productivity, but more was needed Maintains balance in line gains a total 217% productivity improvement since July 2004 Note further adjustment to kanban limit User Acceptance Test

28 Zero Backlog Nov 22 nd 2005 After 12 months team hits zero backlog of change requests November 2004 backlog is 80 and trending upwards A combination of falling demand and 200% productivity improvement meant supply was greater than demand and the backlog was depleted Team wins XIT Team Excellence Award for H2 2005

29 Throughput $ Sep-04 Dec-04 and Cost Lowest cost Highest Productivity per person Mar Jun-05 $2900 Shortest lead time Highest customer satisfaction 56 Zero Backlog achieved Some idle time Lowers metrics Sep-05 $3300 Dec-05 45

30 Mar-04 May-04 Jul-04 Sep-04 Nov-04 Jan-05 Mar-05 May-05 Jul-05 Sep-05 Nov-05 Change Requests 5 Dev Productivity per Resource Dev Test Productivity (per resource) 23 Quarters Zero Backlog achieved Some idle time Lowers metrics

31 Calendar Days Why Lead Time is the best metric XIT-SE TTR From 5 Months To 3 Weeks in 5 Quarters New Manager No More ROMs New Prioritization Process Flow Management Lowest cost Highest Productivity per person FY04 Q4 FY05 Q1 FY05 Q2 FY05 Q3 FY05 Q4 FY06 Q1 FY06 Q2 Quarter Changed dev : test ratio from 3:3 to 4:2 Shortest lead time Highest customer satisfaction Other Sev TTR Sev 1 Zero Backlog Increased dev : test from 4:2 to 5:3

32 Let s take lunch

33 Kanban board and daily standup meeting were introduced in early February 2007 to add a sense of urgency and team collaboration More personal responsibility and accountability Resulted in better visual control Enabled more selforganization Less management supervision Better productivity Spontaneous quality circles and frequent Kaizen events

34 WIP Limit regulates work at each stage in the process WIP limits create a kanban pull system & a white board provides visualization of flow Flow from Engineering Ready to Release Ready Pull

35 Input Queue Analysis In Prog Done Dev Development Ready In Prog Done Kanban board design Build Ready Test Courtesy Olav Maassen QNH Release Ready Stage Prod.

36 Input Queue Analysis In Prog Done Dev Development Ready In Prog Done Flow Kanban board simulation Build Ready Test Courtesy Olav Maassen QNH Release Ready Stage Prod.

37 or use one of the many electronic kanban tools now on the market Agile Zen LeanKit Kanban Silver Catalyst Target Process RadTrack Flow.io Kanbanery Jira + Greenhopper v4.0 FogBugz + Plugin VersionOne Rally(?) Mingle (??)

38 Sticky Buddy scheme was instituted to allow remote workers to keep kanban board up-to-date and synchronized with electronic tracking

39 Exercise 1 Value-stream Modeling Take 15 minutes Split the room into small groups (approx 5 people per group) Collaborate Pick someone in the group. Ask them to describe a workflow from their organization and map the value-stream Create a kanban board to map and track the value-stream Ask Questions you don t know everything you need to know to complete the exercise! For example, how to model concurrency of tasks?

40 Change Requests and Production Bugs Customer valued and prioritized by governing board Define Work Item Types

41 De-lineate non customer-valued work Engineering Defects direct indicator of quality impact on productivity, linked to yellow sticky, not counted against kanban limit

42 Reserve capacity for essential maintenance & upgrades IT Maintenance Work Technology department reserving capacity for its own maintenance difficult to prioritize with business count against kanban limits

43 Types can be derived based on Source Work Item Types E.g. Regulatory Requirement, Field Sales Request, Strategic Planning Feature Workflow Size Items that flow through different steps (or in a different sequence) should be different types, tracked on same board Order of magnitude T-shirt sizes

44 Use swim lanes to lineate type & allocate capacity across lanes Allocation Total = 20 Change Req 12 Maintenance 2 Production Defect Input Queue Analysis In Prog Done Dev Development Ready In Prog Done Build Ready Test = 20 total Release Ready Adapted from design courtesy Olav Maassen QNH...

45 Exercise 2 Work Item Type Definition Take 15 minutes Same groups as before Collaborate Define a set of work item types that flow through the value-stream defined in exercise 1 Decide how to visually communicate work item type for each item in the system Ask Questions you don t know everything you need to know to complete the exercise! For example, how to model hierarchical work item types?

46 Change Requests and Production Bugs Customer valued and prioritized by governing board Classes of Service

47 Process allows for a single Silver Bullet expedite request Silver bullet is hand carried through the system Personal attention from project manager Automatically jumps queues Required specialist resources drop other work in preference to working the silver bullet Release dates may be adjusted to accommodate required delivery date Expediting the Silver Bullet

48 Fixed delivery dates are allowed but not encouraged There are strict rules for date dependent work items E.g. date constrained by legal commitment with customer or supplier, or regulatory requirement (typically in financial systems) Generally, delivery dates are not allowed

49 Temporary classes of work may be introduced tactically to maximize exploitation of the system Extra Bug Special class of production bug, worked by slack developer resources and specially selected not to impact solutions analysis. Tested by developers not testers. Allows maximum exploitation for improved throughput

50 Generally speaking class of service should be defined according to cost of delay function Cost of delay function for an online Easter holiday marketing promotion is difference in integral under two curves

51 Expedite Example classes of service Fixed Delivery Date Unit step cost of delay function (or near approximation) Standard Class Linear tangible cost of delay function Intangible Class Intangible cost of delay Examples brand identity change, usability fix

52 Policies for Expedite Class of Service Expedite requests will be shown with white colored cards. Only one expedite request will be permitted at any given time. In other words, a kanban limit of 1 is assigned to the Expedite class of service. Expedite requests will be pulled immediately by a qualified resource. Other work will be put on-hold to process the expedite request. The kanban limit at any point in the workflow may be exceeded in order to accommodate the expedite request. If necessary a special (off-cycle) release will be planned to put the expedite request in production as early as possible.

53 Policies for Fixed Date Class of Service Fixed delivery date items will use purple colored cards. The required delivery date will be displayed on the bottom right hand corner of the card. Fixed delivery dates will receive some analysis and an estimate of size and effort may be made to assess the flow time. If the item is large it may be broken up into smaller items. Each smaller item will be assessed independently to see whether it qualifies as a fixed delivery date item. Fixed delivery date items will be held in the backlog until close to the point where they must enter the system in order to be delivered ontime given the flow time estimate. Fixed delivery date items will be given priority of selection for the input queue at the appropriate time. Fixed delivery date items will be pulled in preference to other less risky items. In this example, the will be pulled in preference to everything except expedite requests. Unlike expedite requests, fixed delivery date items will not involve putting other work aside or exceeding the kanban limit. If a fixed delivery date items gets behind and release on the desired date becomes less likely it may be promoted in class of service to an expedite request.

54 Policies for Standard Class of Service Standard class items will use yellow colored cards Standard class items will be prioritized into the input queue based on an agreed mechanism such as democratic voting and will typically be selected based on their cost of delay or business value Standard class items will use First in, First out (FIFO) queuing approach to prioritize their pull through the system. Typically when given an option a team member will pull the oldest standard class item from an available set of standard class items ready for the next step in the process Standard class items will queue for release when they are complete and ready for release. They will be released in the next scheduled release No estimation will be performed to determine a level of effort or flow time. Standard class items may be analyzed for size. Large items may be broken down into smaller items. Each item may be queued and flowed separately

55 Policies for Intangible Class of Service Intangible class items will use green colored cards. Intangible class items will be prioritized into the input queue based on an agreed mechanism such as democratic voting and will typically be selected based on their intangible business value. Intangible class items will be pulled through the system in an ad hoc fashion. Team members may choose to pull an intangible class item regardless of its entry date so long as a higher class item is not available as a preference. Intangible class items will queue for release when they are complete and ready for release. They will be released in the next scheduled release. No estimation will be performed to determine a level of effort or flow time. Intangible class items may be analyzed for size. Large items may be broken down into smaller items. Each item may be queued and flowed separately. Typically, the preference would be to put aside an intangible class item in order to process an expedite request. It is therefore sensible and shows a good spread of risk when intangible class items are flowing through the system.

56 Use Color to de-lineate class of service and allocate capacity across classes to manage risk Allocation 1 = 5% 4 = 20% 10 = 50% 6 = 30% = 20 total Input Queue Analysis In Prog Done Dev Development Ready In Prog Done Build Ready Test Release Ready Adapted from design courtesy Olav Maassen QNH...

57 Exercise 3 Classes of service Take 15 minutes Same groups as before Discuss the different classes of service that might apply Draw some example cost of delay curves Show how cost of delay is driving your choice of classes of service Define policies for processing each classes of service Decide how to visually communicate classes of service note that class of service should be unambiguous from work item type

58 Kanban tickets hold a lot of information that enable decentralized control and local decision making when deciding priority of items to pull through the system Electronic ID number Date Accepted clock starts on SLA Assigned engineer Issue attached to change request indicates management attention required Hard delivery date for regulatory, legal, or strategic reasons Signifies item that has exceeded SLA indicates that item should be prioritized if possible

59 Exercise 4 Design Work Item Tracking Card Take 15 minutes Same groups as before Collaborate Design the layout of a kanban wall card What information will you and the team need in order to adequately self-organize and flow work through the system Ask Questions you don t know everything you need to know to complete the exercise! For example, how will pull prioritization be decided?

60 WIP limits should be set based on policies and empirically adjusted up/down over time WIP Limit defined via policies tuned to organizational maturity

61 Examples of WIP Limit Policies Each person should work on no more than 2 items at a time Hence, limit = number of people x 2 Prioritization cadence and coordination meeting will be once per week Hence, input queue must be large enough for one week of pull Mathematically, input queue should be 3 sigma upper control limit of mean throughput (rate of pull)

62 General Observations about Kanban Limits Lower limits are better Less work-in-progress (WIP) Lower cycle times More agile More value delivery Tight lower limits inflict pain on the organization Tight limits will cause work to stall (no flow) Requires good skill in issue management & resolution (impediment removal) Requires capability in root cause analysis and resolution Lower maturity organizations should have looser limits Higher maturity organizations tighter limits

63 Kanban limits can be grouped across work columns and queues (or buffers) Kanban Limit of 4 for analysis and analysis complete queue Kanban Limit similar policy for development and development complete

64 Exercise 5 Setting Kanban Limits Take 15 minutes Same groups as before Collaborate Discuss policies for queues Discuss policies for work columns Discuss organizational maturity Set limits according to agreed policies and maturity Ask Questions you don t know everything you need to know to complete the exercise! For example, would separating out different sizes of work item, allow us to reduce queue sizes?

65 Scaling Kanban

66 Major Project with two-tiered kanban board using swim lanes for feature sets Swim lanes control WIP limit Requirement WIP (green) controlled by number of lanes

67 Small generalist team assigned to each swim lane responsible for feature breakdown and flow Feature Team names of team members assigned to swim lane

68 Cross-functional resources are shown with small orange tickets attached to features Shared resources e.g. enterprise data architect

69 Handling Cross-team Dependency Tag Work Items with Shared Resource Dependency Clearly mark as impeded Provides visibility onto the problem Provide shared resource with separate Kanban board/system Allow several sources of dependency to compete for scarce resource Treat Integration Items as Fixed Date class of service Base fixed date on agreed integration point

70 End of Day 1 Retrospective Take 5 minutes From today s tutorial, what have you learned? What questions do you have for tomorrow? Where do you believe Kanban would be useful? In what situations might Kanban be inappropriate or sub-optimal to implement? Why?

71 Models (to identify improvement opportunities)

72 3 Sources of Improvement Manage Bottlenecks (improve flow, deliver more value) Improve Economic Costs (reduce waste/overheads) Reduce Variability (Chance & Assignable Cause)

73 Economic Costs (waste identification)

74 What is efficiency?

75 What s the most efficient way to paint a fence?

76 Setup Focusing on efficiency produces better cost accounting results for large batch sizes Q Queue Queue Task Queue Task Time Task Wait Wait Task W Wait Cleanup

77 Because the transaction costs (in this case, the setup and cleanup) can be amortized over a greater number of value items (in this case, painted sections of fence)

78 But there are also coordination costs in knowledge work problems Setup Q Queue Queue Task Communication Queue Task Time Task Wait Wait Task W Wait Cleanup

79 And in knowledge work problems, coordination costs grow non-linearly with batch size Setup Q Queue Queue Task Communication Queue Task Time Task Wait Wait Task W Wait Cleanup

80 The prevailing paradigm in Western management was that overheads (transaction and coordination costs) were inevitable and efficiency was achieved through economies of scale (i.e. large batch sizes)

81 Sources of Waste Transaction Costs Coordination Costs Failure Load

82 Waste is Waste Thinking of startup, coordination and delivery tasks as waste is perplexing for most knowledge workers. Call them costs instead

83 cost Transaction Costs Transaction Costs Coordination Costs Value-added Work Failure Load time

84 Bad Good

85 Sources of Economic Costs Transaction Costs Coordination Costs Failure Load

86 Take 15 minutes Exercise 6 Cadence What s the correct release cadence for your kanban system? What are the transaction costs of a release? (training, deployment, governance) and the lead times involved (e.g. training lead time)? What is the appropriate input / prioritization cadence? How quickly are things changing? (in the business) If you reduce waste how might this affect cadence? Does it make sense for release cadence and prioritization to be the same?

87 Exercise 7 Economic Cost Identification Take 15 minutes Same groups Identify transaction costs in your project work Identify coordination costs How much of the total effort on projects, do you estimate is transaction or coordination costs (rather than value-added) effort? Estimate Failure load internal (bugs) and external (escaped) sources Draw a sketch of economic cost model based on data

88 Focus on Quality (Reduce Failure Load)

89 Too much WIP increases defect rates in a non-linear fashion

90 Defects have an opportunity cost Blue tickets are defects defects increase WIP, reduce the team s ability to work on valuable new features and lengthen lead time

91 Quantity of blue tickets on the board is an immediate indicator of development quality that is impeding flow of customer valued work and reducing throughput Engineering Defects direct indicator of quality impact on productivity

92 Defects have an opportunity cost In turn defects increase WIP, lengthen lead times and may result in yet more defects

93 Features Track WIP! WIP is directly related to Lead Time and Quality Feb Device Management Ike II Cumulative Flow 17-Feb 24-Feb Lead Time WIP 2-Mar 9-Mar Time 16-Mar 23-Mar Inventory Started Designed Coded Complete 30-Mar

94 9-Oct 23-Oct 6-Nov 20-Nov 4-Dec 18-Dec 1-Jan 15-Jan 29-Jan 12-Feb 26-Feb 11-Mar Features Too much WIP, 3 month lead time led to a 30x reduction in quality compared to 1 week lead time Project B Cumulative Flow Lead Time Time Inventory Started Designed Coded Complete

95 Defects have an opportunity cost In turn defects increase WIP, lengthen lead times and may result in yet more defects Too much WIP increases complexity and adds additional communication overhead

96 Defects have an opportunity cost In turn defects increase WIP, lengthen lead times and may result in yet more defects Too much WIP increases complexity and adds additional communication overhead By far the easiest way to increase throughput and reduce lead time is to focus on quality

97 Focus on Quality Measure, Track and Manage WIP Employ policies to minimize defects Design and Code reviews Static and Dynamic Code Analysis Test-first development Automated unit tests Continuous integration Formal system testing by professional testers Develop and test in small batches Provide developers with defect feedback as early as possible and as often as possible Enforce as much quality discipline with your configuration management tool as possible E.g. no check-in without passing unit tests

98 Exercise 10 Policies for Quality Take 15 minutes What policies might you set to positively affect quality? How will these policies affect workflow? Will kanban limits have to be adjusted? Which policies might be overridden when required? Can quality policies be related to classes of service? Ask Questions you don t know everything you need to know! For example, how should defects be handled in the workflow?

99 Manage Bottlenecks

100 Known max productivity Working Code Manage bottlenecks to increase productivity Idea Analysis Design Code 1. Identify - Current CCR is System Test 30 per month 2. Exploit - Testers relieved of all non-essential tasks, extra PMs assigned to complete administrative tasks, analysts assigned to future test plans 3. Subordinate - Requirements release restricted to ~30 per month Quality ~90 ~80 ~50 ~50 Error Acceptance Test Error System Test Unit Test Error ~80 ~30 ~40 ~50 Quality Schedule 4. Elevate - Plan to recruit temporary testing staff immediately Schedule How do I trim 25% off the schedule for a project going through this system?

101 Iteration 1 Burndown

102 Iteration 1 Cumulative Flow

103 Burndown versus Cumulative Flow Comparison

104 CR Only Business encouraged to re-triage backlog CR, Bugs and PDUs WIP growth due to additional resource allocation (good) and some sloppy management of kanban limits (bad) Cumulative Flow

105 Looks like a bottleneck Non-instant Availability Same thinking process applies Management approach is similar but policies will be different depending on type of bottleneck CCR vs NIA

106 Exercise 6 Bottleneck Management Take 15 minutes Same groups as before Where do you think there are bottlenecks in your workflow? Is it a CCR or an NIA type bottleneck? What actions would you take to maximize the utilization of your bottleneck resource? What policies are required to subordinate everything else to your exploitation decision? What policies would you remove or change? What new policies must you introduce?

107 Understanding Variability

108 How do event planners do it? Scheduling Wimbledon isn t an exact science Games last different lengths of time and weather conditions can stop play altogether but the Men s Final always happens on the 2nd Sunday If only we could project manage like this! Wimbledon comes in on time every year Except 2004 when it rained on Sunday and the final was on Monday ;-)

109 Working Code Where is the constraint now? Idea Analysis Design Code ~ ~ ~ ~50+-5 ~ ~50+-5 Error Acceptance Test System Test Unit Test 1. Variability variation in Design, Code or Unit Test can move the constraint 2. Plan Insecure Plan based on System Test as CCR is insecure 3. Reduce Variability Change methods in Design, Code & System Test to reduce variability 4. CCR has Narrowest Variability System Test as CCR should have narrowest variability Error Error ~ ~ ~40+-5 ~50+-5

110 Quantity of pink issue tickets on board directly indicates flow impacting problems that need attention from management Issues are the exception attached to work items that are blocked for external reasons and call attention to problems preventing smooth flow

111 Issue Management Cumulative Flow

112 Exercise 7 Classifying Variability Take 15 minutes Same groups as before List the policies under your control that affect the time taken to complete value-added work e.g. Code Inspections, Customer Review What levers can you pull and how might they affect risk? e.g. removing code inspections List typical events out of your control that randomize your plans and schedules What actions might you take to mitigate the effects of these external events Can classes of service be used to help with risk mitigation?

113 Kaizen Culture

114 Map the value stream and track work on a white board Hold a standup meeting every day in front of the board

115 or create an application that looks like a whiteboard but provides the archival advantage of an electronic system

116 Kanban uses a daily standup meeting as a central enabler of a Kaizen culture In this example more than 40 people attend a standup for a large project with 6 concurrent development teams. The meeting is usually completed in approximately 10 minutes. Never more than 15.

117 Manage quantitatively and objectively using only a few simple metrics Quality WIP (work-in-progress) Lead time (against target and DDP) Issue & Blocked Work Throughput Cycle Time Efficiency Across these: Trend Variation

118 Hold a monthly Operations Review and present all the data, invite anyone who wants to come

119 Kanban sets an expectation of High Maturity Root cause analysis on defects stop the line CAR Kaizen events OID

120 Educate the workforce to recognize process problems that affect performance

121 Look how the board has changed by March! Empirically adjusted Kanban limits reacting to industrial engineering issues. Much neater presentation pride in the process is forming

122 And again in April, more changes to Kanban limits and forward extension of the process to business analysis

123 Waste bin spontaneously introduced by team to visually communicate rejected CRs that wasted energy and sucked productivity

124 A report was created to detail rejected or cancelled work items (muda)

125 Kanban has allowed us to observe known industrial engineering issues Expediting impacts throughput and lead time Tends to increase WIP Overly large CRs cause ragged flow, blow out lead time Larger variation in CR size has required larger queues and buffers extending lead time Non-constraints exhibit ragged flow behavior due to non-instant availability e.g. integration build Bottlenecks create ragged flow (e.g. Test) but also experience idle time from upstream ragged flow from non-instant availability stations (e.g. Build) Big items are now broken up, temporarily breaks the Kanban limit but pull system means no new items enter WIP until overflow is depleted. Result is smoother flow even with big items

126 Spontaneous Quality Circles started forming Kanban board gives visibility into process issues ragged flow, transaction costs of releases or transfers through stages in process, bottlenecks Daily standup provides forum for spontaneous association to attack process issues affecting productivity and lead time For example, 3 day freeze on test environment was a transaction cost on release that caused a bottleneck at build state. This was reduced to 24 hours after a 3 person quality circle formed to investigate the policies behind the freeze. Result was improved smooth flow resulting in higher throughput and shorter lead time

127 Other spontaneous quality circle kaizen events Empirically adjusted kanban limits several times E.g. test kanban too small, causing ragged flow UAT state added Prompted by test who were experiencing slack time Expanded kanban limit on Build Ready state, added Test Ready state Introduced to smooth flow post release due to environment outage transaction cost Introduced kanban board, daily standup, colored post-it notes for different classes of service, notations on the post-its Poor requirements causing downstream waste resulted in an upstream inspection to eliminate issues with poorly specified requests

128 In general, empirical observation of ragged flow or visibility of waste generates a quality circle resulting in a kaizen event

129 September 2007 Business Analysis and Systems Analysis merged eliminating 25% of lead time consumed as queuing waste

130 And the process spread inside Corbis

131 And externally at companies like Yahoo!

132 this one on the Mash social network team

133 And the technique is being introduced to major projects with much longer time horizons. This example has a monthly integration event rather than a release every two weeks

134 5 months later significant changes are evident

135 Major project with two-tiered kanban board

136 Major Project with two-tiered kanban board using swim lanes for feature sets

137 Less mature major project in trouble adopts kanban to bring a focus to daily routine and visibility to work-inprogress to team and management

138 Next Day Team is maturing quickly and has refactored the board with swim lanes for functional areas

139 More and more reports were demanded to facilitate management decisions. In this case, new reports to facilitate weekly prioritization

140 Completed items are collected on the wall to the right hand side of the board. Visual indicator of cumulative total of value delivered Management instituted a bottle tops saving scheme where completed items are traded against morale events to celebrate success E.g. movie tickets, bowling evening, trip to Gameworks

141 Executive Dashboard

142 Days SLA Mean Lead Time Trend Mean Lead Time Trend Dec Jan Feb Mar Apr May CRs Bugs Combo

143 CRs & Bugs # CRs Lead Time Distribution Days Lead Time Distribution Due Date Performance Detail Majority of CRs range 30 -> 55 Outliers Days MARCH APRIL

144 Take 15 minutes Exercise 12 Metrics What metrics would you track? Who is the audience for the metrics? Can you identify day-to-day (leading indicator) metrics used for management intervention? Versus weekly, monthly, quarterly (lagging indicator) metrics used for executive reporting, customer satisfaction and assessment of continuous improvement?

145 Culture Change Summary Trust, empowerment, objective data measurement, collaborative team working and focus on quality Policy Changes Late-binding release scope, no estimating, latebinding prioritization Cycle time, Release Cadence and Prioritization Cadence are decoupled Cross-functional collaboration Previously unheard of VP level selfless collaboration on business priority Self-regulating process robust to gaming and abuse Continuous Improvement Increased throughput, high quality, process continually evolving, kanban limits empirically adjusted

146 And finally, staff take a pride in their achievements

147 Day 2 Retrospective What will you change? Take 5 minutes What have you learned today? What one thing will you implement as a change in your organization when you get back to the office this week? How far do you think Lean/Kanban can take your organization? Take 5 minutes to discuss your results and share with the group

148 Thank you!

149 David Anderson is a thought leader in managing effective software teams. He leads a consulting firm dedicated to improving economic performance of knowledge worker businesses improving agility, reducing cycle times, improving productivity and efficiency in technology development. He has 25+ years experience in the software industry starting with computer games in the early 1980 s. He has led software teams delivering superior productivity and quality using innovative agile methods. He developed MSF for CMMI Process Improvement for Microsoft. He is a co-author of the SEI Technical Note, CMMI and Agile: Why not embrace both! David s book, Agile Management for Software Engineering Applying the Theory of Constraints for Business Results, introduced many ideas from Lean and Theory of Constraints into software engineering. David was a founder of the Lean Software & Systems Consortium, a not for profit dedicated to promoting better standards of professionalism and effectiveness in software engineering. dja@agilemanagement.net About