2. Kanban So*ware Engineering

Size: px

Start display at page:

Download "2. Kanban So*ware Engineering"

Emma Perkins
5 years ago
Views:

1 2. Kanban So*ware Engineering 1

2 Enterprise So*ware Engineering Agenda 1. CMMI and Scrum 2. Kanban So*ware Engineering 3. So*ware Development Life Cycle 4. Secure So*ware Engineering 2

3 Agile Past (... some 3 years ago)

4 Agile Present

5 Scrum Problems

6 Length of IteraHons (% respondents) No Iterations > 8 Weeks 7-8 Weeks 1,4 1,9 1,9 5-6 Weeks 4 Weeks 6, % 3 Weeks 12,5 2 Weeks 32,6 1 Week 17 < 1 Week 5 Scott W. Ambler, Agile Adoption Survey

7 Short IteraHons (Hme- boxes) Advantages: More effec(ve feedback More effec(ve itera(ons (sprints) planning 7

8 Short IteraHons (Hme- boxes) Disadvantages: Smaller stories are o;en too small to be valuable and difficult to iden(fy In the backlog of smaller stories could be hundreds of items, instead of couple dozen in Kent Beck s days (extreme programming). New problem of management of stories has emerged. 8

9 Conclusions Doing Scrum well is very difficult. Most teams do not reliably deliver their sprint commitment by the end of the sprint. There is no one right way to do Scrum. Both "Successful" and "Improvable teams come in all sizes and configurahons. At least up to a point, more stories per sprint are beyer. It looks like 10 to 15 is a good number. Most teams should consider slicing their stories smaller. Very big stories are are unlikely to be completed in the sprint, but an occasional moderately sized story doesn't look like it's a problem. 9

10 Testers Race in the End of Sprint Development work o*en conhnues throughout a cycle while teshng starts late and never seems to get enough Hme 10

11 11

12 OK, Let s kanban now

13 Kanban Takes the Best from the Buffet 13

14 Lean

15 Lean Thinking Taiichi Ohno 15

16 Kanban 16

17 Kanban A card ayached to boxes of parts that regulates pull in the Lean System by signaling upstream produchon and delivery. 17

18 Kanban So*ware Development David Anderson "No one's job title Agile 2007 conference changes, that inihally no sparked one's roles widespread and interest in responsibilities Kanban change, and any changes that we do make will be made incrementally." 18

19 19

20 Waste in So*ware Development 20

21 Primary Goal: Eliminate Waste Any achvity that consumes resources but creates no value is waste 21

22 Mura Muri Muda 22

23 Level out the Load Heijunka There is a relahon between the three principles: mura creates muri leading to the inability to reduce muda. Waste can be reduced through solving problems with imbalanced loading and overstraining of people Avoid unevenness: Mura Avoid overburdening: Muri Heijunka 23

24 David Anderson: 24

25 Scrum PracHces could be Sources of Waste 25

26 26

27 Using a Kanban approach in so*ware drops Hmeboxed iterahons in favor of focusing on con3nuous flow. 27

28 28

29 29

30 Kanban has 3 Rules, and Simple Mechanics 30

31 Kanban in Nutshell Pull value through the Value Stream Limit WIP Make it visible! 31

32 Pull Don t build features that nobody needs right now Don t write more specs than you can code Don t write more code than you can test Don t test more code than you can deploy 32

33 Pull When a customer requests a given feature for a so*ware product, they want to pull that feature out of teshng so that they can start using it. 33

34 Pull Once that feature has been moved out of TesHng and the customer is ready to pull the next feature out, there isn't anything to pull. At this point, the TesHng people would then try to pull the next feature out of Development. 34

35 Pull And the same pull happens from Analysis to Development. 35

36 LimiHng Work In Progress (WIP) Given a value stream, a WIP limit governs the number of work items that can be in a given state at any instant. 36

37 A Minimal Marketable Feature (MMF) A minimal marketable feature (MMF) is a chunk of funchonality that delivers a subset of the customer s requirements, and that is capable of returning value to the customer when released as an independent enhty. 37

38 MMF 38

Rolling Wave Planning Different planning buckets for

MMFs 3 month bucket: loosely- defined features 6

strategies, goals, market forces Update ALL of the

39 Rolling Wave Planning Different planning buckets for different Hme horizons: 6 week bucket: well- defined MMFs 3 month bucket: loosely- defined features 6 month bucket: broad feature areas 1 year bucket: strategies, goals, market forces Update ALL of the buckets once every 6 weeks OR every Hme an MMF completes. 39

40 Cycle Time 40

41 Cycle Time and Lead Time 41

42 CumulaHve Flow Diagram 42

43 Disclaimer No Engineering Prac3ces Looks Simple, Is Hard No Silver Bullet Not Complete Takes Time

44 Henrik Kniberg Scrum vs. Kanban Mattias Skarin 44

45 Scrum versus Kanban Product Management 45

46 Kanban Limits WIP per Workflow State, Scrum Limits WIP per IteraHon 46

47 Scrum Resists Change within an IteraHon 47

48 What if someone turns up and wants to add E to the Kanban board? A Kanban might say Feel free to add E to the To Do column. But the limit is 2 for that column, so you will need to remove C or D in that case. We are working on A and B right now, but as soon as we have capacity we will pull in the top item from To Do. 48

49 Scrum Board is Reset between each IteraHon 49

50 Scrum Prescribes CrossfuncHonal Teams 50

51 Kanban could have Specialised Teams The whole board is served by one cross-functional team. Just like Scrum. The product owner sets priorities in column 1. A crossfunctional development team does development (column 2) and test (column 3). Release (column 4) is done by a specialist team. There is slight overlap in competencies, so if the release team becomes a bottleneck one of the developers will help them. 51

52 Scrum Backlog Items must fit in a Sprint A Scrum team will only commit to items that they think they can complete within one iterahon. If an item is too big to fit in a sprint, the team and product owner will try to find ways to break it into smaller pieces unhl it does fit. 52

53 Kanban can have Long Running Items Kanban indirectly creates an incenhve to break items into relahvely small pieces. But there is no explicit rule stahng that items must be small enough to fit into a specific Hme box. 53

54 Scrum Prescribes EsHmaHon and Velocity 54

55 Scrum Prescribes EsHmaHon and Velocity 55

56 Scrum s Development Cycle When the sprint is done, the team delivers potenhally shippable code to the product owner. So the team finishes the sprint, does a sprint review, and proudly demonstrates features A, B, C, and D to the product owner. 56

57 Full Development Cycle in Kanban 57

58 Kanban Daily MeeHngs 58

59 59

60 The Kanban Approach to Change is Based on 3 Principles 1.Start with what you do now 2.Agree to pursue incremental, evoluhonary change 3.IniHally, respect current processes, roles, responsibilihes & job Htles 60

61 J- curve Effect 61

62 Many CIOs Feel the Need to Shake Things up And Leave their Mark CEO and Chairman of the Board of Hewlett-Packard 62

63 Scaling So*ware Agility

65 Why to Scale Agile? Small (5 9 people) Colocated - Cross- func3onal Self- organized - Full- 3me 65

66 So*ware Value Stream 66

67 Blockages Occur in Value Stream 67

68 The Agile Planning Onion

69 Goals of Portolio Management

70 Portolio, Programs, Projects

71 Scaling Agile

72 Stories, Features and Epics Feature 72

73 Epic Epics collections of features, typically 1-3 months in duration. Epics span releases. Epics can span more than one team. Portfolio elements. Feature Features are smaller than epics, typically 2-4 weeks in duration. Features are contained within releases. Features are contained within a team. Program elements. User Story User Stories are the smallest increment of value, typically less than a week. Project elements.

74 Epic Epics are decomposed into Features that describe the value added into the product Feature

75 Epic Epics are decomposed into Features that describe the value added into the product Feature Feature

76 Epic Epics are decomposed into Features that describe the value added into the product Feature Feature Feature

77 Epic Epics are decomposed into Features that describe the value added into the product Feature Feature Feature Feature

78 Epic Features are decomposed into User Stories that are thin slices of value added into the system Feature Feature Feature Feature

79 Epic Features are decomposed into User Stories that are thin slices of value added into the system Feature Feature Feature Feature

80 Epic Features are decomposed into User Stories that are thin slices of value added into the system Feature Feature Feature Feature

81 Epic Features are decomposed into User Stories that are thin slices of value added into the system Feature Feature Feature Feature

82 Minimally Marketable Features feed the prioritization of Sprint Planning Story Backlog Task Backlog In Process Task Done Story Backlog

83 Identify the most likely to contribute to the MMF and build that one first Story Backlog Task Backlog In Process Task Done Story Done

84 Identify the most likely to contribute to the MMF and build that one first Story Backlog Task Backlog In Process Task Done Story Done 3

85 Pull User Stories in priority order focusing on delivering complete MMFs Story Backlog Task Backlog In Process Task Done Story Backlog 3

86 Pull User Stories in priority order focusing on delivering complete MMFs Story Backlog Task Backlog In Process Task Done Story Backlog 3 2

87 User Stories across MMFs Story Backlog Task Backlog In Process Task Done Story Backlog 3 2

88 User Stories across MMFs Story Backlog Task Backlog In Process Task Done Story Backlog 3 2 1

89 The team uses its past velocity to determine how many stories go in the Sprint Story Backlog Task Backlog In Process Task Done Story Backlog 3 2 1

90 The Team breaks each User Story down into Tasks Story Backlog Task Backlog In Process Task Done Story Backlog 3 Task Task Task 2 1

91 The Team breaks each User Story down into Tasks Story Backlog Task Backlog In Process Task Done Story Backlog 3 Task Task Task 2 Task Task Task Task 1

92 The Team breaks each User Story down into Tasks Story Backlog Task Backlog In Process Task Done Story Backlog 3 Task Task Task 2 Task Task Task Task 1 Task Task Task Task

93 RUP What? How? Do! Deliver! Milestones Understand the problem Understand the solution Solution ready? Acceptance from the customer 93

94 Inception Elaboration Construction Transition Epic Tier 3 - Kanban Analysis Design Build Test Deploy Feature Tier 2 - Kanban Story Backlog Task Backlog In Process Task Done Story Done Tier 1 - Scrum

95 Inception Elaboration Construction Transition Epic Epic Analysis Design Build Test Deploy Feature Feature Story Backlog Task Backlog In Process Task Done Story Backlog Spike Task Task Task

96 Inception Elaboration Construction Transition Epic Epic Epic Epic Analysis Design Build Test Deploy Feature Feature Feature Feature Feature Feature Story Backlog Task Backlog In Process Task Done Story Backlog Spike Task 8 Task Task 8 Task 8 Task 8 Task Task 8 8 Task 8 Spike

97 Scrum Team Team Agility

98 MulH- Team Agility Scrum Team Scrum Team

99 MulH- Team Agility Scrum Team Scrum Team Scrum Team

100 MulH- Team Agility Scrum Team Scrum Team Scrum Team Scrum Team

101 Program Agility Program Team Scrum Team Scrum Team Scrum Team Scrum Team

102 Program Agility Program Team Program Team Scrum Team Scrum Team Scrum Team Scrum Team

103 Portolio Agility Portfolio Team Program Team Program Team Scrum Team Scrum Team Scrum Team Scrum Team

104 Enterprise Agility Strategy Team Portfolio Team Support Product Team Product Team Scrum Team Scrum Team Scrum Team Scrum Team

105 105

106 5 Reasons for Applying Kanban 1. Ability to release any3me Scrum and XP, usually do not release in the middle of the sprint. This is not the case with Kanban. 2. Ability to change priori3es on the fly Scrum is reluctant to change the priorihes in the middle of the sprint. In Kanban, if there is an urgent request to implement or a really important user story, the team can just put it on top of the queue. 3. No need in itera3ons IteraHons are perfect for gevng into a rhythm. However, a*er a point, when the flow is established, iterahons could rather become a waste. 4. No need in es3mates Just as iterahons, eshmates could also become a waste. You can take the most important user story from backlog and implement it. 5. Perfect flow visualiza3on - Kanban Board provides a very clear view on current work in progress. It visualizes flow and enables fast planning and tracking. 106

107 Why Kanban? Q: Scrum works flawlessly for all of my teams. Why overly complicate things by adding Kanban constraints? A: Kanban is built for compehhon. Maybe you are not in a compehhve situahon. Maybe your compehtors are inept. If, however, you are under any pressure for systemahc performance improvement, then the Kanban address inefficiencies that are built into Scrum. 107

108 Kanban & Agile 108

109 But remember: Kanban is (only) a TOOL 109

110 110

111 111

112 112

113 CMMI & Kanban love and marriage 113

114 114

115 115

116 From Traditional To Agile and Kanban Software Engineering: More Fun, Happy Teams 116

De-Mystifying Kanban:

De-Mystifying Kanban: Understanding Its Many Faces Kanban kanban Al Shalloway Co-founder of, no longer affiliated with, Lean-Kanban University LKU Kanban (Kanban Method) Open Kanban Team Kanban Kanban