Download presentation
Presentation is loading. Please wait.
1
Lean Software Development
C LE COËNT
2
Agenda Introduction the 8 lean software principles
lean kanban for agile project management: Success story Beyond Scrum, XP, Lean Kanban
3
Intro. : the way I have approached SW
SCRUM WATERFALL
4
Lean Software Principles
Created by Mary and Tom Poppendieck (link) Initially 7 principles, now 8 principles
5
1 optimise the whole Lean Software Development
The whole is the system we are in a cmplex system, optimising parts of the system is not optimal: example is waterfall Cooperation is best way to work so any decision we can be assessed prior to implementation, agreed with parties, implemented and finally we can measure the impact on the company and customers We maintain synergie: we could have optimised ticket resolution and then project work (as they did with scrum): we created synergie: 2 streams, one team- we optimise the whole We appreciate our value streams: different classes of service We have an E2E view: from creating the product backlog to getting final feedback from customers.
6
Complex Adaptive System
Optimising the parts sub-optimises the whole !!!WATERFALL!!!
7
How to optimise the whole?
By creating synergies: Increase cooperation (Y. Morieux, Smart Simplictiy) Cross-functional teams Remove silos “You build it, you run it” (amazon) By thinking long term Aligning people on the same goal(s) By appreciating the entire value stream
8
Appreciate the value stream: from concept to cash
6 months waiting, meetings, specifying 1 month Dev. 2 months Testing, changes, Retesting 1 month Waiting
9
2 focus on customers Lean Software Development
The whole is the system we are in a cmplex system, optimising parts of the system is not optimal: example is waterfall Cooperation is best way to work so any decision we can be assessed prior to implementation, agreed with parties, implemented and finally we can measure the impact on the company and customers We maintain synergie: we could have optimised ticket resolution and then project work (as they did with scrum): we created synergie: 2 streams, one team- we optimise the whole We appreciate our value streams: different classes of service We have an E2E view: from creating the product backlog to getting final feedback from customers.
10
How to focus on customers
Ask the right questions Design thinking: Solve the right problems Painkillers vs. Vitamins Design a great experience Importance of UX design
11
2007
12
3 energize workers Lean Software Development
The whole is the system we are in a cmplex system, optimising parts of the system is not optimal: example is waterfall Cooperation is best way to work so any decision we can be assessed prior to implementation, agreed with parties, implemented and finally we can measure the impact on the company and customers We maintain synergie: we could have optimised ticket resolution and then project work (as they did with scrum): we created synergie: 2 streams, one team- we optimise the whole We appreciate our value streams: different classes of service We have an E2E view: from creating the product backlog to getting final feedback from customers.
13
How to energyze workers – scare resources
SENSE OF PURPOSE: Vision of the product we want to build SEMI-AUTONOMOUS TEAM WITH INTERNAL LEADER (captain?) AUTONOMY: Make their own decisions, choices Improve their own processes CHALLENGE MASTERY Be better at doing things: Quality Get better skills
14
4 reduce friction Lean Software Development
The whole is the system we are in a cmplex system, optimising parts of the system is not optimal: example is waterfall Cooperation is best way to work so any decision we can be assessed prior to implementation, agreed with parties, implemented and finally we can measure the impact on the company and customers We maintain synergie: we could have optimised ticket resolution and then project work (as they did with scrum): we created synergie: 2 streams, one team- we optimise the whole We appreciate our value streams: different classes of service We have an E2E view: from creating the product backlog to getting final feedback from customers.
15
DOUBLE LOOP LEARNING (CHRIS ARGYRIS)
Example of buidling the product wrong: a depedant team delivering poor quality… Forced to ship when this is not ready
16
FRICTION: WIP Gets obsolete Causes task switching:
Extra 40% of effort for a given task Delays realisation of value Poor quality (hide defects)
17
5 enhance learning Lean Software Development
The whole is the system we are in a cmplex system, optimising parts of the system is not optimal: example is waterfall Cooperation is best way to work so any decision we can be assessed prior to implementation, agreed with parties, implemented and finally we can measure the impact on the company and customers We maintain synergie: we could have optimised ticket resolution and then project work (as they did with scrum): we created synergie: 2 streams, one team- we optimise the whole We appreciate our value streams: different classes of service We have an E2E view: from creating the product backlog to getting final feedback from customers.
18
BIGGEST CONSTRAINT ON A PROJECT?
19
Learning by doing: shared experiment board
Learning opportunities Expected outcome Results & observations What did we learn? Add extra step to break down stories in less than 3 points Higher speed (velocity) and quality We have more A/C tests than usual Higher velocity lower variability, less rework!!! Analyse usage of features by customers Identify features requiring tweaking Performance is poor on some key features Run a Kata on TDD (Bowling) over 2 weeks, 30 mns a day Realisation that TDD is powerful & must be used Indeed, this is very robust way to spec a product and easy Give it a go to tests as spec
20
6 increase flow Lean Software Development
The whole is the system we are in a cmplex system, optimising parts of the system is not optimal: example is waterfall Cooperation is best way to work so any decision we can be assessed prior to implementation, agreed with parties, implemented and finally we can measure the impact on the company and customers We maintain synergie: we could have optimised ticket resolution and then project work (as they did with scrum): we created synergie: 2 streams, one team- we optimise the whole We appreciate our value streams: different classes of service We have an E2E view: from creating the product backlog to getting final feedback from customers.
21
Speed, Quality and Low Cost are?
Compatible NOT compatible Call a friend 50-50? Waterfall vs. Scrum Waterfall to Scrum: increases speed and quality by smaller batches and quicker feedback, implementing BDD, TDD, using user stories….
22
Kanban vs. Scrum: flow vs. task-based
SCRUM: break user stories into tasks Sprint backlog To do In progress Done Design 6h User Story 8 pts Write accep. tests 4h Approved by P.O Released Implement API1 8h Implement API2 8h Code Review 4h Run tests 4h KANBAN: break user stories into smaller user stories Product Backlog Analysis: UX + small US < 3d + Acc. tests Dev + code review + tests passing Agile Testing: exploratory, load, … Released 4 4 5 US: BIZ Rule 1 Cycle time US: BIZ Rule 2 User Story 8 pts US: BIZ Rule 3 Lead time
23
How to improve flow:
24
How to split stories: Ref. link
25
7 build in Quality Lean Software Development
The whole is the system we are in a cmplex system, optimising parts of the system is not optimal: example is waterfall Cooperation is best way to work so any decision we can be assessed prior to implementation, agreed with parties, implemented and finally we can measure the impact on the company and customers We maintain synergie: we could have optimised ticket resolution and then project work (as they did with scrum): we created synergie: 2 streams, one team- we optimise the whole We appreciate our value streams: different classes of service We have an E2E view: from creating the product backlog to getting final feedback from customers.
26
How to build Quality in Find and fix defects where they occur
Mistake-proof the system: Think tests as specification BDD / Specification by Examples / ATDD / TDD Integrate early and often: DevOps: part of the value stream Don’t tolerate defects: Have you planned for « stabilisation sprint »? … FIX IT HERE!
27
TDD Pour les méthodes à Gilles, toujours besoin d’au moins un Dédé!
You do not write code that does not contribute to tests: Only write new code because of a failing test KISS - Keep It Simple Stupid Write just enough code so the test passes YAGNI: You aren’t gonna to need it DRY: Don’t Repeat Yourself: Eliminate duplication A great kata: link Write a failing test Write just enough code so the test passes Refactor tests and code Pour les méthodes à Gilles, toujours besoin d’au moins un Dédé!
28
8 keep getting better Lean Software Development
The whole is the system we are in a cmplex system, optimising parts of the system is not optimal: example is waterfall Cooperation is best way to work so any decision we can be assessed prior to implementation, agreed with parties, implemented and finally we can measure the impact on the company and customers We maintain synergie: we could have optimised ticket resolution and then project work (as they did with scrum): we created synergie: 2 streams, one team- we optimise the whole We appreciate our value streams: different classes of service We have an E2E view: from creating the product backlog to getting final feedback from customers.
29
Keep getting better Yesterday’s wisdom is today’s obstacle and tomorrow’s folly: If waterfall is the day before yesterday’s wisdom, what is yesterday’s wisdom? Focus on outcome rather than outputs “This is not about changing, this is about changing faster than your competitors!”
30
8 principles Optimise the whole Synergy and cooperation
How to Optimise the whole Synergy and cooperation Focus on customers Solving customer’s right problems Energise workers Sense of purpose, autonomy, mastery (stop “multitasking”) Reduce friction Getting early feedback to build right product Enhance learning Maintaining an idea backlog for the team Improve flow Split user stories x Reduce WIP Build in Quality Find and fix bugs where they occur Keep getting better Change as fast as the world changes
31
One issue… 8 lean software development principles
But what framework(s)? Example: implementing these principles using Kanban
32
Lean kanban for agile project management A success story
33
Real case scenario
34
(use of) Scrum rejected
« compliance to the process »: scope must be defined or, for this application : Priorities keep changing New features keep appearing With the team & the customer, we decided to EXPERIMENT with Kanban
35
Kanban for Project Management (Eric Brechner)
HOW TO GET STARTED: Step 1: Capture your team’s high-level routine Step 2: Redecorate your wall Step 3: Set limits on chaos Step 4: Define done Step 5: Run your daily standup
36
Step 1: Capture your team’s high-level routine
2 types of items: incidents and user stories For any work item: We analyse the item We implement the item (local env.) We validate the item (test env.) We deliver the item (validation env.) We follow when the item goes to PROD
37
Step 2: Redecorate the wall
High level team’s routine Product Backlog Implemented (local env.) Validated (test env.) Delivered (next env.) Analysed Prod Incidents User stories Identify classes of service
38
Step 3: Set limits on chaos
WIP Limit: empirical! Product Backlog Implemented (local env.) Validated (test env.) Delivered (next env.) Analysed Prod 5 4 10 10 Incidents User stories
39
Step 4: Define done Product Backlog Implemented (local env.) Validated
Done rules: Tickets: impact assessed and documented User stories: < 3 days, estimated RCA for rework Done rules: User stories: shadowing complete, knowledge shared, documented Done rules: User stories: reviewed complete Done rules: Tickets: customer has closed the ticket User stories: tested and no defects Product Backlog Implemented (local env.) Validated (test env.) Delivered (next env.) Analysed Prod 5 4 10 10 Tickets Doing Done Doing Done Doing Done Doing Done User stories Doing Done Doing Done Doing Done Doing Done
40
Step 5: Run your daily standup
Start from the right side of the board: Most valuable items should be on the right Start finishing Speed “Do we see any impediment that prevents us from moving user story #123 to the next column?” Keep moving from right to left: Repeat with next user stories until 15 mns are over If there is any item blocked, mark it “blocked” and capture an action Step 5: Run your daily standup Done rules: Tickets: biz justification and due date User stories: < 5 days, estimated RCA for rework Done rules: User stories: shadowing complete, knowledge shared, documented Done rules: User stories: reviewed complete Done rules: Tickets: customer has closed the ticket User stories: feedback received Product Backlog Implemented (local env.) Validated (test env.) Delivered (next env.) Analysed Prod 5 4 10 10 Tickets Doing Done Doing Done Doing Done Doing Done Development Doing Done Doing Done Doing Done Doing Done 2 1 20 3 8 5
41
Done rules updated on the fly WIP has been reduced and respected
Step 5: a few weeks later Done rules: Tickets: biz justification and due date User stories: < 5 days, estimated RCA for rework Done rules: User stories: shadowing complete, knowledge shared, documented Done rules: User stories: reviewed complete Done rules: Tickets: customer has closed the ticket User stories: feedback received Done rules updated on the fly Product Backlog Implemented (local env.) Validated (test env.) Delivered (next env.) Analysed Prod 3 4 4 3 Tickets WIP has been reduced and respected Doing Done Doing Done Doing Done Doing Done Pre-analysis by team Queue Doing Done Doing Done Doing Done Doing Done Doing Done 6 2 2 0.5 1 3 2 3 1 2 5 0.5
42
Metrics: Cumulative Flow Diagram
WIP Lead time Cycle time
43
Other routines Planning & grooming: Priorities can change:
Flow-based: on request (with buffer) Priorities can change: e.g. if capacity is available, user stories can be pulled in (there is no rule though) Estimating and long term planning Story points & avg. number of points delivered Cadence: Retrospective every 2 weeks
44
Were we lean? Optimise the whole Cooperation with end users
Principles How to Optimise the whole Cooperation with end users Focus on customers We understand end users’ problem Energise workers Far better dynamic, 0% attrition Reduce friction Getting user stories right, quality right Enhance learning Learnt about kanban Improve flow Split user stories x Reduce WIP Build in Quality Writing tests before writing code Keep getting better Kept updating “done” rules
45
Success story: conclusion
Lean kanban: is lean is very effective: Using some of the scrum practices, we had a very robust framework offers little resistance and is simple because it starts with the way the team works makes “continuous improvement” easier makes issues more obvious (visual approach) Lean kanban works well for software development projects
46
Beyond Scrum, XP and Lean Kanban
47
Leanban… Al Shalloway - netobjectives
48
3rd generation: Leanban
Lean - Scrum Cross-functional team Sprints provide discipline Even small batches Self-organizing Daily meetings Improve flow Focus on finishing Everything visible Explicit workflow Manage WIP User stories / story points ATDD Lean - Kanban Create teams to extend possible Adopt cadence Lean XP Test Driven Design/Dev. (TDD) Pair programming Continuous Integration Automation testing
49
Lean scrum: power of visualisation
SLICING Features With examples Groomed Sprint backlog To Do In progress Done User stories integrated & QA Released Feedback
50
Conclusion Keep in mind the 8 lean principles:
That will help you find (better) solutions Lean kanban is an effective way of managing projects If you don’t know where to start, lean kanban may provide the path of least resistance If you are using a framework like scrum or XP, you could make your approach more “lean” And introduce the team(s) to a set of proven practices Enabling you to optimise the whole
51
References (1) Objectif Reference Authors To get started with kanban
Agile Project Management with Kanban (developer best practices) (2015) Erich Brechner How lean kanban is used Real-world Kanban, do less, accomplish more with Lean Thinking (2015) Mattias Skarin Optimising the whole Six Simples Rules: How to manage complexity without getting complicated Yves Morieux Smart simplicity video ted.com To explain 7 lean principles Lean Software Development: an agile toolkit (2003) Mary and Tom Poppendeick To know more about kanban including buffers and slack Essential Kanban Condensed (2016) David J Anderson, Andy Carmichael
52
References (2) Objectif Link Authors
Leanban: to make your framework more lean Leanban Pocket guide (2016) Alan Shalloway and James R Trott Spec by examples Specification by Example Dojko Adzic What is BDD and how to use it with your PO BDD in action John Ferguson Smart Foreword by Dan North Motivation (book) amazon Dan Pink Motivation (videos) youtube Bowling Kata for TDD Microsoft Virtual Academia link SPIDR: how to break user stories Mike Cohn
53
1st generation Scrum Kanban XP Cross-functional team
Sprints provide discipline Kanban Improve flows with existing structure Focus on finishing Everything visible Explicit workflow Manage WIP XP Test Driven Design/Dev. Pair programming Continuous Integration Automation testing User stories / story points Small batches Self-organizing Daily meetings
54
2nd generation Lean Kanban Scrum Create teams to extend possible
Improve flows with existing structure Focus on finishing Everything visible Create teams to extend possible Explicit workflow Adopt cadence Manage WIP User stories / story points Scrum Cross-functional team Sprints provide discipline XP Test Driven Design/Dev. Pair programming Continuous Integration Automation testing User story points / story points Small batches Self-organizing Daily meetings
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.