3. Zahnärztekasse AG
●
around 35 employees
●
offers financial services to dentists, mainly in
connection with processing invoices
●
total value of processed invoices:
over CHF 250 million per year
●
IT (obviously) plays a central role
●
more information: http://www.zakag.ch/
6. Scrum – elevator pitch (1)
“Agile Software Development with Scrum” by Ken Schwaber
and Mike Beedle, p. 82:
Jeff Sutherland, VP of Engineering,
went to the President of Easel
Corporation, and asked him, "Have
you ever seen a development team
to meet a traditional project plan."
8. Scrum – elevator pitch (3)
Jeff said, "I think the only thing
you can trust is working software
that the team can demo. If you give
the team complete freedom for 30
day Sprints, at the end of the
Sprint you will see exactly where the
product is, for better or worse."
9. Scrum – elevator pitch (4)
He said, "Fine, for the first time I
will know where product development
really stands and can make the
appropriate decisions. I'm willing to
take the risk of giving the team
autonomy for defined periods."
10. Scrum – roles
●
Product Owner: decides on the direction of
development – what will be developed in what
order
●
Scrum Master: helps the team to be successful,
in particular by removing obstacles to higher
productivity
●
Team: is responsible for delivering the software
with top quality in small increments
11. Scrum is a broad church
There is more variation out there – and for good
reasons! – than some people might like
12. Scrumban
●
Scrumban = Scrum + kanban :)
●
the name was coined by Corey Ladas in a
slightly inflammatory article:
http://leansoftwareengineering.com/ksse/scrumban/
●
here kanban = kanban system for software
development (a Lean tool)
13. Kanban systems
●
kanban systems for software development are
task/story boards on steroids
●
you saw a very basic one on the first slide:
14. Kanban systems
●
there are some good introductions by well
known members of the agile community:
–
http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
– http://agileproductdesign.com/blog/2009/kanban_over_simplified.html
●
on InfoQ you can find a presentation by David
Anderson, one of the leading lights of the
kanban enthusiasts:
– http://www.infoq.com/presentations/kanbanforsoftware
15. Now you know ...
●
what kind of company I work for
●
how to describe Scrum in thirty seconds
●
where this horrible new term “Scrumban”
comes from
16. Inhouse software development
●
most of our software development enables and
supports internal operations
●
most of our users are in the same building
●
there is only one installation
●
the senior developers have full control over the
production environment (of course, with
great power comes great responsibility!)
17. Inhouse software development
●
all this simplifies software development a lot
(I know I used to work for a software company
with commercial products)
●
the problem of inhouse software development
is that its importance tends to be underrated
(because it "just costs" money)
●
it is much harder to justify the kind of budget
needed for serious development
18. Before Scrum
●
at Zahnärztekasse AG, the dominant pattern
had been to define small development projects
and to assign these projects to individual
members of the staff (who thus became "project
managers", but this was usually just one of
many tasks for them)
●
this had worked reasonably well, but there were
several disadvantages:
19. Before Scrum
●
productivity suffered from multitasking (too
many projects stayed "90% complete" for too
long)
●
there was too little collaboration among the
development staff, which had a negative impact
on design quality
●
there was usually not enough momentum for a
systematic improvement of the infrastructure
20. A new project
●
in the first half of 2008 a consensus emerged
that the time had come for modernizing the core
infrastructure and the user interface
●
we had many ideas for improvements that
together would have a measurable positive
effect on the business
21. A new project
●
however, the project manager (myself), doubling
as architect and developer, was mostly busy
with another project
●
the other core developer was also busy with
other projects and tended to prefer to work
remotely
●
plus, we didn't have an expert in the GUI
technology
22. A new project
●
progress on this supposedly very important
project was predictably slow
23. Introducing Scrum
●
I had experience with a "homegrown" agile
process and automated regression tests (in a
domain where such tests are still uncommon)
●
I was determined to introduce a "real" agile
development process
24. Introducing Scrum
●
I considered Extreme Programming, but feared
that management would not see the point
●
I also feared that we would never manage to
faithfully stick to all those "extreme" practices
25. Introducing Scrum
●
Scrum is more "managementoriented" there
is nothing that doesn't make sense to a good
manager
●
in particular in our case, Scrum and the basic
assumptions behind Scrum were a very good fit
for the management philosophy of the CEO
26. Introducing Scrum
●
the CEO had already played a Product Owner
like role, including shielding developers from
direct "urgent" feature requests by stakeholders
●
the CEO had already come to value progress in
small steps and the ability to rapidly react to
market opportunities
27. Introducing Scrum
●
we invited Peter Stevens to introduce the
development team and in particular the CEO
to the key concepts of Scrum, and then officially
decided to use Scrum
●
in October 2008 I took a Scrum Master class
with Jeff Sutherland
●
I was determined to implement Scrum properly
28. First steps
●
Product: all internally developed software,
divided into subsystems
●
Product Owner: CEO
●
Scrum Master: myself
●
Team: development staff including myself
29. Lack of progress on “main” project
●
the first three sprints were definitely “ScrumButt”
(but also an exercise in the “art of the possible”)
●
we continued to work more or less like before,
until it was painfully obvious that progress on the
"main" project was far too slow
●
it is one thing to know that focus and collocation
are beneficial, it is another thing to make it
happen
33. Impediments get removed
key decisions in February 2009:
●
the CEO as the Product Owner saw that
insufficient capacity was partly to blame and
increased the budget
●
I myself in my reincarnation as a Scrum Master
insisted on the developers working together in
the same room at least most of the time
34. Collocation
●
I promised the CEO 40% higher productivity if we
work together in an adequately equipped team
room (that was Jeff Sutherland's estimate)
●
collocated development (three days per week)
started in March 2009
42. Collocation
●
comparing the three Sprints before and the three
Sprints after partial! collocation, average
velocity has actually doubled *
* based on data as of 20.05.2009
43. Collocation
●
although there is one more fulltime team
member there are still only two developers who
do most of the actual work
●
there has been a genuine and substantial
improvement in productivity per developer, and
this has been recognized by everybody involved
●
there are more factors involved, but 40% can
safely be attributed to collocation
44. Collocation
●
having the team work together in one room,
insisting on concentrated work and keeping
distractions away is the key for improving
efficiency and quality
●
close collaboration with users is another key
ingredient for success
●
if you have read about Crystal, this will sound
familiar :)
46. Bandwidth of communication
if the three
people involved
had been working
in the same room
all this would have
taken less than
ten minutes
47. Removal of further impediments
●
one developer (“MaCa”) was and is critical for
rapid progress
●
the dramatic improvement in productivity is to
some extent due to the optimization of the
whole environment for this key developer
49. Project health
●
the Product Owner/sponsor is happy with our
progress, and has great expectations for the
future
●
morale is high – the team takes pride in the
quality of the design and in adopting
established professional practices, in particular
test and build automation
50. Project health
●
mind you this is a domain where automated
regression tests are still not mainstream –
indeed many would think that in our case
automated tests are just too much work or even
downright impossible
●
kudos to Gojco Adzic for DbFit, which has been
a godsend for us I don't know what we would
have done without it!
51. “Something old, something new,
something borrowed
and something blue”
●
what I have described so far is more or less
standard Scrum (or Crystal)
●
now comes the kanban part
52. Kanban board
●
in the first collocated Sprint I introduced a kanban
board in order to make our whole "value stream"
visible
●
as a first approximation, you may think of this
kanban board as a standard Scrum story board
that is extended to the left to include steps to
prepare backlog items for development and
to the right to include the steps coming after
development until a feature is finally in production
54. Kanban board
●
ESTIMATED
●
PREPARE
●
READY
●
NEXT
●
DEVELOPMENT
●
DEVELOPED
●
INSTALLED
●
BEING USED
55. Kanban board
●
this kanban board allows me to visually control
the flow of all of our work in particular:
– I want to see where work "gets stuck"
– I want to see if downstream steps risk getting
starved
56. Kanban board
●
note that there is a rough space limit on the
number of items in each column
●
(I've cheated a bit, actually)
●
kanban experts take this a lot further and make
an art of getting the limits right
57. Lean
●
in Lean thinking there is an emphasis on speed,
on competing on speed
●
the ideal is to get "from concept to cash" in a
rapid flow
●
improving quality and decreasing cost are so to
speak side effects of this quest for speed
●
ask General Motors if it works :)
58. Lean
●
in our case, the "concepts" are small features
and feature enhancements, normally estimated
at between 1 and 8 ideal person days of effort
●
small or at least uniformly sized units of work
can help to improve throughput
●
in our case, "cash" is whatever benefit is
realized by the use of the feature
59. Inventory
●
at the risk of oversimplifying a little: In Lean,
inventory is the enemy, is "waste"
●
this is an interesting idea in the context of
software development: what is our inventory?
●
our inventory is features that have been thought
about and worked on, but are not yet in
production
60. Inventory
●
in particular, preparing a month's worth of
backlog items for development – as needed for
Sprint planning – means building up inventory
●
I feared this would require a lot of effort and
would distract us from development
●
it would be more in the spirit of Lean to prepare
each backlog item just in time for development
63. Inventory
●
as it turns out, towards the end of the Sprint it is
usually relatively easy to see how the items at
the top of the backlog should be implemented
●
this is due to the increase of knowledge during
the development of the previous features
64. Inventory
●
this can be compared to driving a car at night –
as one drives, the headlights always show the
next part of the road
65. Inventory
●
the monthly rhythm of the review and planning
meetings with our CEO has served us well
●
since building up the Sprint planning inventory
doesn't cost us much effort and since it is
usually (almost) entirely consumed at the end of
a Sprint we don't need to be too worried about
this inventory
66. Inventory
●
in fact, the monthly planning rhythm allows us to
concentrate on development for at least three
weeks in a row
●
in our case this is probably more efficient
67. Inventory
●
remember though that we only track small
features and feature enhancements, not tasks
●
features are decomposed into tasks justintime
– a second Sprint planning meeting by the book
for four weeks' worth of work would kill us :(
●
shorter iterations are not an option – our
Product Owner is the CEO, we have to keep the
overhead for him as small as possible
68. Inventory
●
much more serious are delays and inventory
further downstream features that are already
developed, but not yet in production
69. Inventory
●
every day a “done” feature is not actually used
in production the business loses a day's worth
of benefit from using the feature
●
perhaps more importantly, the developers and
the Product Owner! don't get any feedback
from production and may make bad decisions
based on false assumptions
70. Cumulative flow diagram
●
cumulative flow diagrams are a great way to
visualize the flow in a kanban system
●
I introduced a cumulative flow diagram at the
beginning of our second collocated Sprint
73. Cumulative flow diagram
Cumulative Flow Diagram
160
140
120
100 ESTIMATED
IN PROGRESS
80 DEVELOPED
INSTALLED
60 BEING USED
40
20
0
01.04.2009 06.04.2009 11.04.2009 16.04.2009 21.04.2009 26.04.2009 01.05.2009 06.05.2009 11.05.2009 16.05.2009
74. Cumulative flow diagram
●
it came as a slight shock to see how slowly
features move into production
●
here is certainly plenty of room for improvement
●
however, in cases where a set of small features
is only relevant as a whole it is natural for the
feature set to "build up" in a staging area such
as DEVELOPED before the set as a whole
moves into production
75. Efficiency and effectiveness
●
what ultimately matters to the sponsor is not
“requirements” or “features” but whether the
changes to the system have the desired effect
on the business (effectiveness)
●
if features and feature enhancements move into
production fast enough (efficiency), the sponsor
and the developers have a chance to maximize
effectiveness based on feedback
76. Efficiency and effectiveness
I would like to conclude the main part of my
talk with a passage from
Extreme Programming Explained:
Embrace Change
by Kent Beck
77. Learning to drive (1)
“Extreme Programming explained” (1st edition) by Kent Beck,
p. 27+28:
[...] I jerked back to attention as
the car hit the gravel. My mom
(her courage now amazes me) gently
got the car back straight on the
road.
79. Learning to drive (3)
“Driving is not about getting the car
going in the right direction. Driving
is about constantly paying attention,
making a little correction this way, a
little correction that way.”
80. Learning to drive (4)
This is the paradigm of XP.
[...] The driver of a software
project is the customer.
[...] Our job as programmers is to
give the customer a steering wheel
and give them feedback about where
we are on the road.
81. Bonus Material: Crystal Clear
●
Crystal Clear is a minimalist methodology for
small teams extracted by Alistair Cockburn
(remember: the best frameworks are extracted)
●
The result of ten years of debriefing successful
small teams – originally for IBM
●
If you are trying to implement Scrum, you have
started to deliver good results, and everybody
on the project is happy, you are probably
already using it :)
83. Crystal Clear – roles
●
sponsor (corresponds to Product Owner –
depending on how Product Owner role is
implemented)
●
at least one senior designer (often also
coordinating the project)
●
team of designerprogrammers collaborating
with expert users
84. Crystal Clear – targeted properties
●
frequent delivery
●
reflective improvement
●
osmotic communication
●
personal safety (a basic level of trust)
●
focus
●
easy access to expert users
●
technical environment with automated tests,
configuration management, and frequent
integration
92. Reading tips
Agile Software Development and
Crystal Clear* by Alistair Cockburn and
Agile Project Management by Jim Highsmith –
arguably the best books on Scrum around –
after Ken Schwaber's writings of course :)
*chapter 1 is the most lighthearted
and enchanting introduction to agile
software development you can
imagine
93. Reading tips
Organizational Patterns of Agile Software
Development by Jim Coplien and Neil Harrison
– based on “empirical studies of about 100
organizations”, originally for Bell Laboratories
Jim Coplien is one of the true thought leaders of
the agile movement (he seems to have a high
opinion of Scrum, by the way)
94. Reading tips
Lean Software Development and Implementing
Lean Software Development by Mary and Tom
Poppendieck – guess who wrote the
forewords :)
Scrumban – Essays on Kanban Systems for
Lean Software Development by Corey Ladas –
some very clever writing questioning
mainstream agile thinking
95. Reading tips
Scaling Lean & Agile Development by Craig
Larman and Bas Vodde – a very recent (2009)
book by solid agile practitioners with a deep
understanding of Lean and the application of
systems thinking and queueing theory –
cautioning against going overboard with
isolated Lean techniques (in particular kanban)
96. Reading tips
About Face – The Essentials of Interaction
Design by Alan Cooper et al.
the ideas in this book can help a lot to make
software development more effective (as
opposed to merely efficient)
also have a look at Jeff Patton's blog:
http://agileproductdesign.com/blog/