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
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
20.
21.
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
28.
29.
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
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
55.
56.
57.
58.
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
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
Notas del editor
Causes:Long lead timeHard to plan
There’s always a reason.Example: emptying water from a boat. Do something about the reason!
In Scrum and Kanban you are supposed to add stuff.In RUP, you are supposed to remove stuff.Scrum + XPKanban + daily standupScrum team using use cases or limiting WIPDon’t call it Scrum if it isn’t.