The document outlines a lean software development methodology, influenced by kanban principles, highlighting the inefficiencies of traditional waterfall models and emphasizing agile practices. It discusses key concepts such as limiting work in progress, improving flow, and the importance of collaboration among cross-functional teams. The presentation also addresses the need for continuous improvement, visualizing workflows, and managing expectations to enhance software delivery efficiency.

1. An introduction to a lean-styled
software development methodology

2.  John Nuechterlein aka jdn
 „Professional‟ IT experience since 1996
 Ph.D. in Philosophy, University of Miami
 Experience in Operations – SQL Development -
.NET Development
 Industry experience in retail
eCommerce, Finance, Manufacturing

3.  Henrik Kniberg (slides used under Creative Commons License)
 David Anderson
 Corey Ladas
 Ron Jeffries
 Jesper Boeg
 Many others

4.  A very condensed and somewhat inaccurate
description of common software development
practices
 Not designed to „prove‟ kanban is always right
(because it isn‟t)
 Highlight common flaws in traditional
waterfall software development and how the
industry has sought to resolve them

5.  A phrase introduced by Chris Matts on the
yahoo message group to differentiate the very
basics of kanban from the very sophisticated
versions that existed at the time and exist
currently
 David Anderson seemed to regard it as an
acceptable phrase
 What I am presenting today is the very basics
and should not be thought to be
comprehensive
 What do you expect? I have an hour.

6.  Relationship between lean and kanban is
murky
 Lean tends to focus on „waste‟ while kanban
generally avoids talking about it
 Lean software development is more likely to „match
up‟ with lean manufacturing, while kanban
generally rejects the linkage
 In the end, it‟s somewhat irrelevant

7.  http://www.nouveautech.co.uk/waterfallprocess.html

8.  A regimented process that attempts to follow a
logical process in order to bring a software
development project to fruition
 Requirements
 Determine the requirements that meet business
needs
 Design
 Determine the design/architecture that will fulfill
those requirements
 Coding
 Produce the code that will implement the design

9.  Test
 Execute the designed test scenarios to prove that the
code fulfills the original business requirements
 Implementation
 Implement the software according to the accepted
practices of the business
 Support
 Support the software according to the accepted
practices of the business

10.  Seems to mirror other physical development, such
as building projects, but they are radically different
 Change requests
 An „end user‟ can‟t ask you to change the design of the 2nd
floor of a 40 floor building after it is built, but end users of
software can and often do request the equivalent
 Technology choice
 Building materials are largely constrained, but there are few
constraints on how you implement software
 Should it be a web app or windows app, should it be java or
c#, should it use infragistics or wpf, etc.
 You can‟t build a building using tapioca
 But you can build software using vbscript, foxpro, etc.
 Even though you shouldn‟t

11.  Estimation paradox
 The amount of time spent in estimation
produces a problem it was designed to
manage

12.  Estimation paradox, cont.
 All significant projects require estimation (especially
capital intensive ones) but, paradoxically, the more
detailed the estimation:
 The longer it takes to produce
 The more it requires negotiation to cover each item
 The longer it takes to get approved when it is „all or
nothing‟
 Thus, increasingly delaying the project itself and
offering more opportunities for the project to fail

13.  Unrealistic specificity
 On 9/24/2011, at 2:30 PM, jdn will implement the
function that adds a workflow step to fulfill business
requirement X
 X-factor ignorance
 The ancillary events that impact product
schedule, e.g. the external XYZ database in UAT
goes down for a week
 It is rare that „x-factors‟ are built into the plan, even
though they always occur

14.  Fails the „fail fast‟ principle
 The first real point at which a requirement can be
found to be lacking is during QA
 Way too late, wasteful, quicker feedback is required
 Too many tasks/projects in flight at once
 Start early != finish early
 E.g. we are gathering requirements on 12 items, but
have yet to deliver any of them

15.  Government contracts
 “Let‟s iteratively develop as we go along” isn‟t going to
cut it
 Significant Infrastructure Projects
 E.g, moving from Sybase to Oracle
 “Let‟s iteratively determine requirements” isn‟t going to
cut it
 Real engineering
 Software developed for things like:
 Nuclear power plants
 Space probes
 Red-green-refactor isn‟t going to cut it

16. www.agilemanifesto.org
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

17.  Individuals and interactions over processes and tools
 “This isn‟t working” -> “this is the process that has been defined”
 Broken processes prevent individuals from making improvements, especially
when they are „take it or leave it‟
 Working software over comprehensive documentation
 “We met the business requirement with feedback from the user” -> “This isn‟t
the exact requirement in the document we signed off on”
 Functioning software is stymied because it doesn‟t exactly match a document
 Customer collaboration over contract negotiation
 “Here is how we implemented the requirements” -> “This isn‟t how we agreed
to implement what is on page 12, section 3.4”
 Lack of trust turns software development into a haggle over negotiating terms
 Responding to change over following a plan
 “Circumstances have arisen that required a change in plan” -> “This isn‟t the
plan, we all agreed on the plan”
 Inability to be truly agile in response to changing circumstances, and
circumstances always change

18. Principles behind the Agile Manifesto
Our highest priority is to satisfy the Working software is the primary
customer through early and continuous measure of progress.
delivery of valuable software. Agile processes promote sustainable
Welcome changing requirements, even late development. The sponsors, developers,
in development. Agile processes harness and users should be able to maintain a
change for the customer's competitive constant pace indefinitely.
advantage. Continuous attention to technical
Deliver working software frequently, from excellence and good design enhances
a couple of weeks to a couple of months, agility.
with a preference to the shorter timescale. Simplicity--the art of maximizing the
Business people and developers must work amount of work not done--is essential.
together daily throughout the project. The best architectures, requirements,
Build projects around motivated and designs emerge from self-organizing
individuals. Give them the environment and teams.
support they need, and trust them to get At regular intervals, the team reflects on
the job done. how to become more effective, then
The most efficient and effective method of tunes and adjusts its behavior
conveying information to and within a accordingly.
development team is face-to-face
conversation.
18

19.  A set of development practices
 Pair programming
 Two developers program a feature together
 Reduction in bugs, increased knowledge across team
members
 Continuous process
 Continuous integration gives quick feedback on breaking
code changes
 Frequent releases that provide concrete value
 Collective code ownership
 Any team member should be allowed to change any code
 Increased knowledge across team members
 Sustainable pace
 Eliminate death march projects that require continual
overtime which burns out team members

22.  Develop in iterations
 Industry coalescing around 2 week period
 Once the tasks for an iteration are defined, they do
not change
 Clearly defined product owner
 PO defines priorities
 PO interfaces with both the dev team and
stakeholders
 PO speaks with one voice

23.  Clearly defined scrum master
 Maintains the overall process
 Removes impediments to the team
 Daily standup
 What I did yesterday
 What I am going to do today
 What is getting in my way

24.  Product Backlog
 High-level list of potential features
 Ordered by business value
 Owned by Product Owner
 Sprint Backlog
 List of work to be done in the next sprint
 Tasks „assigned‟ by the team, not assigned by
anyone else
 Business can‟t change tasks inside of a sprint

25.  Cross-functional team
 No „specialists‟, instead a group consisting of
members who can tackle the wide range of needs
across the software platform
 Demo each iteration
 Working, tested software demonstrated
 Immediate feedback from stakeholders
 Retrospective
 After each sprint, discuss what worked well, what
didn‟t, what needs to change for the next sprint

26.  Continual Delivery
 Small team spending a little time building a small
thing, instead of a large group spending a long time
building a huge thing, but releasing often
 No scope creep
 Tight requirements defined upfront and designed in
short increments
 Reasonable expectations
 Because each sprint is timeboxed, the number of
tasks is limited and targeted

27.  Very short feedback cycles
 Does the software work
 Scrum is best when combined with XP
 Quick feedback that the code works
 Does the created software do what the customer
wanted it to do
 It is inevitable that the customer will say that they want
X, but when you give them X, they will realize they
really wanted Y
 This is inevitable. So, finding this out at the end of a 2
week sprint is much better than finding this out 5
months into a 6 month project schedule

30.  Scrum prescribes organizational change up
front as you need:
 Product owner
 Scrum master
 Cross-functional team
 Keymaster, GateKeeper, Oracle
 Exaggerating, but you get the point
 Prescribed organizational change is
scary, e.g., “I‟m about to lose my job or have it
redefined without my approval”

31.  It is difficult to have truly cross-functional
teams
 when the dev team doesn‟t control the
implementation
 Separate dedicated external teams that control
 DB
 Networking
 Migration
 Sometimes, specialization is necessary
 E.g., knowledge of networking is not easy to come by
 Deep knowledge of particular areas of technology
necessarily means more shallow knowledge in other
areas

32.  Splitting a long project into multiple sprints has
its own overhead cost
 Some tasks will take longer than whatever sprint
length you set
 Some projects are hard to split into discrete tasks
 Especially when it involves external parties, whether
inside the business or 3rd party vendors
 I took a week-long (or less) course and am now
certified
 Sure you are

33.  Scrum gives you a description of the sweet spot
for software development.
 If you or your organization can‟t implement it, that‟s
a problem with you or your organization, not with
Scrum
 If your organization could properly develop
software, it wouldn‟t need to change. If it
can‟t, it needs to change.
 Life is hard.
 If roles need to change to fix things, they need to
change

34.  A long history, but short version:
 Developed by David Anderson while working as a
consultant at Microsoft circa 2004
 A distillation of common emerging practices
 Vaguely related to Lean Manufacturing as
developed by Toyota
 Improved over time as many other practitioners
started with the principles and then saw what
worked
 A work in progress, based on real-world
implementations

35. http://blog.crisp.se/henrikkniberg/tags/kanban/
Henrik Kniberg 35

36. Dev
Backlog Next 3 In production :o)
2
Ongoing Done
A
B
G
C
F
D
H
I
J L E
M K
Henrik Kniberg 36

37. Dev
Backlog Next 3 In production :o)
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 37

38. Dev
Backlog Next 3 In production :o)
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 38

39. Dev
Backlog Next 3 In production :o)
2
Ongoing Done
C A
G
D B
F
H
I
J L E
M K
Henrik Kniberg 39

40. Dev
Backlog Next 3 In production :o)
2
Ongoing Done
C A
G
D B
F
H
I
J L E
M K
Henrik Kniberg 40

41. Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
A
B
G
C
F
D
H
I
J L E
M K
Henrik Kniberg 41

42. Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 42

43. Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
C A
G
D B
F
H
I
J L E
M K
Henrik Kniberg 43

44. Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
C A
G
D B
F
H
I
J L E
M K
Henrik Kniberg 44

45. Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
C A
G
D !? B
F
H
I
J L E
M K
Henrik Kniberg 45

46. Dev
Backlog Nexet 3 In production :o)
2
PO Ongoing Done
G
!? A
D B
F
E C
H
I
J L
M K
Henrik Kniberg 46

47. Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
A
G
D B
F
E C
H
I
J L
M K
Henrik Kniberg 47

48. Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
A
G
D B
F
E C
H
I
J L
M K
Henrik Kniberg 48

49. Dev
Backlog Next 3 In production :o)
2
PO Ongoing Done
D A
G
B
E
F
C
H
I
J L
M K
Henrik Kniberg 49

50.  Start with what you do now
 No immediate changes to any of your current processes
 Agree to pursue incremental, evolutionary change
 Agree across the business that you want to improve what
you do now based on evidence (e.g. metrics)
 We will get evidence on what most immediately needs
improvement, agree on a course of action on how to
improve it, take those actions, and then see if it works
 Respect the current process, roles, responsibilities
& job titles
 No one loses their job or has their job arbitrarily re-
defined
 Individuals get to be part of the process of improving the
processes

51.  Visualize the workflow
 Create a visual representation of your current process, the steps
from A to Z in delivering a software development project
 Where are the bottlenecks? Visualization „surfaces‟ them
 Limit WIP
 Limit what any individual is working on by numerical limits
 Pull in next work items
 Explicitly prevent too many tasks from being assigned at one
time
 Manage flow
 Find where your blocking points are and prioritize working on
those
 Agree on a change to improve flow
 If it works, move on to the next point
 If it doesn‟t, try something else

52.  Make process policies explicit
 Highlight the steps where work moves from one stage to
another (visual representation), and define the process
 When everyone can see the flow, there is a common
understanding of the problems with the process
 Improve collaboratively
 Improve in small continuous increments
 Make some changes and see what works
 Changes are agreed upon across the business
 When small changes are made, it is easier to measure the
impact
 This process never ends. “Lather, rinse, repeat.”

53.  Predictable service delivery
 Once the flow is defined, established and measured
over time, you can get a realistic picture of how long
it will take for a work item to go from start to finish
 Everyone can see the impact of bottlenecks in
particular areas of the flow
 X-factors will always occur, but when you have a
visual representation of where they occur, you can
implement improvements (or at least account for
them) and get a realistic (i.e., measured) estimate of
how it impacts schedule

54.  Making promises you can keep
 Once you can define a predictable service
delivery, you can accurately promise how long a
work item will take
 The business always knows what is in the pipeline
and where it is in the pipeline, and also knows that if
they want to prioritize something else they have to
de-prioritize something in progress
 Visibility into the software development process is
available to anyone

59. Causes of unnecessary multitasking
 Focusing on starting stuff rather
than finishing
 Not limiting WIP
 Focusing on keep people busy
(fear of slack)
 Accepting the “reason” & solving
the symptom instead of the
problem
Henrik Kniberg 59

60. Probably a bit of both.
Physical Digital
• Cheap • Remote
• Easy to evolve access
• Big • History/back
• See all at once up
• Same view • Metrics
• Tangible / Direct
manipulation
• Brings people together
Henrik Kniberg 61

61. More prescriptive More adaptive
RUP XP Scrum Kanban Do Whatever
(120+) (13) (9) (3) (0)
• Architecture Reviewer • Business use case realization
• Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow
• Business-Model Reviewer • Business vision • Coding standard • Product Owner • Limit WIP
• Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time
• Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning
• Change Control Manager • Configuration management • Customer tests meeting
• Code Reviewer plan • Pair programming • Daily Scrum
• Configuration Manager • Data model • Refactoring • Sprint review
• Course Developer • Deployment model • Planning game • Product backlogt
• Database Designer • Deployment plan • Continuous integration • Sprint backlog
• Deployment Manager • Design guidelines • Simple design • BUrndown chart
• Design Reviewer • Design model • Sustainable pace
• Designer • Development case • Metaphor
• Graphic Artist • Development-organization • Small releases
• Implementer assessment
• Integrator • End-user support material
• Process Engineer • Glossary
• Project Manager • Implementation model
• Project Reviewer • Installation artifacts
• Requirements Reviewer • Integration build plan
• Requirements Specifier • Issues list
• Software Architect • Iteration assessment
• Stakeholder • Iteration plan
• System Administrator • Manual styleguide
• System Analyst • Programming guidelines
• Technical Writer • Quality assurance plan
• Test Analyst • Reference architecture
• Test Designer • Release notes
• Test Manager • Requirements attributes
• Tester • Requirements
• Tool Specialist management plan
• User-Interface Designer • Review record
• Architectural analysis • Risk list
• Assess Viability of architectural • Risk management plan
proof-of-concept • Software architecture
• Capsule design document
• Class design • Software development
• Construct architectural proof- plan
of-concept • Software requirements
• Database design specification
• Describe distribution • Stakeholder requests
• Describe the run-time • Status assessment
architecture • Supplementary business
• Design test packages and specification
classes • Supplementary specification
• Develop design guidelines • Target organization assessment
• Develop programming • Test automation architecture
guidelines • Test cases
• Identify design elements • Test environment configuration
• Identify design mechanisms • Test evaluation summary
• Incorporate design elements • Test guidelines
• Prioritize use cases • Test ideas list
• Review the architecture • Test interface specification
• Review the design • Test plan
• Structure the implementation • Test suite
model • Tool guidelines
• Subsystem design • Training materials
• Use-case analysis • Use case model
• Use-case design • Use case package
• Analysis model • Use-case modeling guidelines
• Architectural proof-of-concept • Use-case realization
• Bill of materials • Use-case storyboard
• Business architecture document • User-interface guidelines
• Business case • User-interface prototype
• Business glossary • Vision
• Business modeling guidelines • Work order
Henrik Kniberg 62
• Business object model • Workload analysis model
• Business rules
• Business use case

62. Top 10
Customer
requirements
Top 3
project
impediments
Top 5 Internal
improvements
Henrik Kniberg 63

63. Definition of
”ready for
development”
Definition of
”ready for
system test”
64

64. Team 1 Team 2 Team 3
Henrik Kniberg 65
65

65.  The best thing about Kanban is that it doesn‟t
require you to change your current processes.
The worst thing about Kanban is that it doesn‟t
require you to change your current processes
 Since Kanban is by its nature largely non-
prescriptive compared to other
methodologies, it doesn‟t necessarily tell you
how to proceed