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