SCRUM - ERNI
SCRUM - ERNI
SCRUM - ERNI
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>ERNI</strong> experience reports on management, processes and technology<br />
Experience<br />
nr.54<br />
september 2012<br />
<strong>SCRUM</strong><br />
<strong>SCRUM</strong>: SEttINg<br />
thE RIght CoURSE<br />
Correctly set parameters guarantee<br />
productivity and efficiency.
<strong>SCRUM</strong>: SEttINg<br />
thE RIght CoURSE<br />
Correctly set parameters guarantee<br />
productivity and efficiency.<br />
With the agile and lightweight<br />
development method<br />
Scrum, large software projects<br />
are more manageable<br />
with respect to functionality,<br />
project duration and quality.<br />
In practice, however, this<br />
will only succeed if the basic<br />
parameters are set in a well<br />
thought-out manner. Among<br />
other things, optimal sprint<br />
length and team size, as well<br />
as the balance between functionality<br />
and quality, are of<br />
decisive importance.<br />
By Bruno HEufEldEr and MiCHElE TEdEsCo<br />
In recent years, agile methods for organising<br />
and controlling software development<br />
processes have gained hugely in importance.<br />
Among the various approaches,<br />
especially Scrum is growing in popularity.<br />
The reason for the increasing prevalence<br />
of this extremely slim framework is that,<br />
when using traditional methods, even<br />
very extensive planning is often unable to<br />
improve management security.<br />
While traditional approaches such as the<br />
waterfall model rely on a detailed master<br />
plan, factors such as self-organisation,<br />
direct and rapid generation of benefits,<br />
continuous status checking and adaptation,<br />
as well as the ongoing involvement<br />
of both users and clients are foregrounded<br />
with Scrum (see Fig. 1).<br />
Yet, although long concept phases as well<br />
as detailed product and requirement specifications<br />
are missing, Scrum is anything<br />
but haphazard: The framework stipulates<br />
a fixed set of rules along with well-defined<br />
roles and a clear and flexible workflow<br />
that is repeated cyclically.<br />
The Scrum framework owes its popularity<br />
primarily to its impressive simplicity.<br />
However, quick and easy as it may be to<br />
learn and apply the principles of the<br />
framework, especially for complex projects<br />
it is critical to correctly set a number<br />
of important parameters.<br />
optIMal SpRINt lENgth<br />
At the heart of Scrum is the self-organising<br />
project team, which, in close<br />
consultation with the client, or prod-<br />
uct owner, implements the sub-tasks<br />
at pre-established time intervals. The<br />
aim of these so-called sprints is to generate<br />
executable functions or modules.<br />
Scrum recommends a sprint length of<br />
one to four weeks. Particularly in large<br />
and complex software projects, however,<br />
there is a tendency towards the<br />
maximum sprint length. This may allow<br />
sufficient time buffers to be scheduled,<br />
but frequently undoes the greatest<br />
advantage of Scrum, namely its<br />
flexibility: The feedback loops grow<br />
larger, as do the response times. Furthermore,<br />
to eliminate errors, the team<br />
members repeatedly have to work their<br />
way back into older topics. New requirements<br />
or priorities, which are<br />
prone to change at short intervals in<br />
large-scale projects, can also cause delays.<br />
Subsequently, forward-looking<br />
and, above all, reliable planning becomes<br />
increasingly difficult.<br />
In the case of short change management<br />
cycles, a sprint length of only two<br />
weeks, for example, is therefore highly<br />
advisable. It allows obstacles as well as<br />
changes by individual stakeholders to<br />
be taken into account at an earlier<br />
stage. Moreover, it forces both the<br />
product owner and the team to focus<br />
on the current target.<br />
IdEal tEaM SIzE<br />
Team size is another key success factor.<br />
The framework stipulates a team of no<br />
more than nine members, always coming<br />
from different disciplines so that<br />
all technical requirements can be dealt
at the heart of scrum is the self-organising project<br />
team, which, in close consultation with the client,<br />
or product owner, implements the sub-tasks at preestablished<br />
time intervals. The aim of these socalled<br />
sprints is to generate executable functions or<br />
modules.<br />
sCruM 16 | 17
figure 1: scrum process overview<br />
product<br />
Backlog<br />
product<br />
owner<br />
Sprint<br />
planning<br />
Meeting<br />
Ready done<br />
Sprint<br />
Backlog<br />
(Priorities)<br />
Scrum<br />
Master<br />
team<br />
1–4<br />
Weeks<br />
Sprint<br />
daily<br />
stand-up<br />
Sprint<br />
Review<br />
Customer<br />
potentially<br />
shippable<br />
Sprint<br />
Retrospective<br />
Scrum recommends a sprint length of one to four weeks.<br />
Particularly in large and complex software projects, however,<br />
there is a tendency towards the maximum sprint length.<br />
This may allow sufficient time buffers to be scheduled, but<br />
frequently undoes the greatest advantage of Scrum, namely<br />
its flexibility: The feedback loops grow larger, as do the<br />
response times. Furthermore, to eliminate errors, the team<br />
members repeatedly have to work their way back into older<br />
topics. New requirements or priorities, which are prone to<br />
change at short intervals in large-scale projects, can also<br />
cause delays. Subsequently, forward-looking and, above all,<br />
reliable planning becomes increasingly difficult.
with autonomously. If the team is too<br />
small, it often lacks the expertise required<br />
to implement all tasks in an optimal<br />
manner.<br />
However, if the team size exceeds the<br />
recommended maximum, communication<br />
problems become virtually unavoidable.<br />
The individual members<br />
are no longer able to communicate<br />
with each other in sufficient detail,<br />
and the decision-making process begins<br />
to stretch out. Accordingly, there<br />
is also the risk of losing focus on the<br />
respective iteration targets.<br />
FEatURE vERSUS qUalIty<br />
Budget constraints, ever shorter timeto-market<br />
cycles and technical complexity<br />
form an everyday part of development<br />
projects. They inevitably contribute<br />
to the tension between<br />
functionality and quality. This often<br />
leads to power struggles between the<br />
product owner, who demands the immediate<br />
implementation of new fea-<br />
tures or requirements, and the development<br />
team, which usually wants to<br />
deliver a high-quality product that<br />
corresponds to the so-called ‘definitions<br />
of done’.<br />
If new functionality, in the form of prototypes<br />
and geared only towards shortterm<br />
benefits, is added to a system, then<br />
what is known as technical debt begins<br />
to accumulate: Over time, imperfect<br />
software design, inadequate or no testing,<br />
unclean code or inadvertent complexity<br />
results in a more and more unstable<br />
system that in the worst case can<br />
bring all further development to a halt.<br />
This dilemma can only be resolved if<br />
all parties involved come to realise<br />
that short-term implementation strategies<br />
will not accelerate a development<br />
project. Experience shows that<br />
sooner or later, the technical debt –<br />
plus interest – will have to be paid back<br />
in order to obtain a clean, expandable<br />
and maintainable system.<br />
sCruM 18 | 19<br />
Example 1<br />
WEll thoUght-oUt dIvISIoN<br />
INCREaSES pRodUCtIvIty<br />
The far-advanced development of a<br />
complex embedded system was threatening<br />
to become bogged down. Over<br />
time, one of the project teams involved<br />
had grown unexpectedly and was finally<br />
greater than recommended for Scrum.<br />
Among other things, this meant that<br />
decision-making within the team was<br />
taking longer and longer, and that it was<br />
becoming difficult to keep to the specified<br />
period of 15 minutes for the daily<br />
Scrum meetings.<br />
On the recommendation of Scrum specialists,<br />
and following a more detailed<br />
analysis of the situation, the team was<br />
split into two teams, each with its own<br />
Scrum Master. Because they continue<br />
to share the product owner and product<br />
backlog, optimal coordination between<br />
the two teams was achieved. Today,<br />
the product backlog is divided be
Team size is another key success factor. The framework<br />
stipulates a team of no more than nine members,<br />
always coming from different disciplines so<br />
that all technical requirements can be dealt with<br />
autonomously. if the team is too small, it often<br />
lacks the expertise required to implement all tasks<br />
in an optimal manner.
tween the teams in the sprint planning<br />
meeting. In this way, each team is better<br />
able to focus on its respective tasks.<br />
The daily stand-up meetings and retrospectives<br />
can now be conducted easily<br />
within the scheduled time in the smaller<br />
units. The bottom line is that the well<br />
thought-out splitting increased efficiency<br />
and productivity, while giving a boost<br />
to the employees’ motivation.<br />
Example 2<br />
ShoRtER SpRINtS pREvENt WoRk<br />
BaCklogS<br />
In a complex, multi-year development<br />
project in a technology company, the<br />
length of the sprints in the initialisation<br />
phase was set at one month. Over time,<br />
it became evident that proper planning<br />
for this interval was becoming ever more<br />
difficult. Planning meetings lasted eight<br />
hours and more due to the large number<br />
of user stories that needed to be prepared<br />
for each sprint backlog.<br />
This led to work backlogs and ever-increasing<br />
difficulties in planning longterm<br />
progress. More and more frequently,<br />
the development team was unable to<br />
meet the commitments which it had<br />
undertaken after each sprint planning<br />
meeting to complete the defined tasks.<br />
After a comprehensive analysis of the<br />
situation, the sprint length was shortened<br />
to half a month. This raised the<br />
question within the development team<br />
how the tasks that had previously failed<br />
to be completed in a month could now<br />
be done in half the time. Soon, however,<br />
the marked increase in efficiency due to<br />
the shortened cycles became obvious:<br />
On the one hand, the duration of the<br />
planning meetings dropped to less than<br />
four hours. On the other hand, the team<br />
was considerably more focused and able<br />
to respond more quickly and efficiently<br />
to unexpected matters, on account of<br />
the now manageable time windows and<br />
the increased transparency. The commitments<br />
undertaken became more realistic<br />
and can now largely be met in time,<br />
which greatly improves the planning for<br />
the overall project.<br />
Erni – innovation in Process and Technology<br />
Bruno HEufEldEr<br />
bruno.heufelder@erni.ch<br />
advisory activity: scrum Master,<br />
agile Coach, Project leader<br />
MiCHElE TEdEsCo<br />
michele.tedesco@erni.ch<br />
advisory activity:<br />
software Engineering,<br />
sCruM, Project Management<br />
sCruM 20 | 21
www.erni-consultants.com/experience<br />
enables & delivers<br />
pUBlIShER’S dEtaIlS<br />
publisher<br />
Erni Management services aG<br />
Zurich · Bern · Baar · lausanne<br />
Erni (deutschland) GmbH, Munich<br />
Erni (slovakia) s.r.o., Bratislava<br />
Erni Consulting España, s. l.<br />
Editor<br />
adela novotná, Erni (slovakia) s.r.o.<br />
Tel. +421 2 3255 37 40<br />
leserservice@erni.ch<br />
www.erni.ch/experience<br />
Editorial office<br />
daniel Meierhans,<br />
inhalte.ch GmbH, Zurich<br />
usG Übersetzungs-service aG, ittigen<br />
Concept/layout<br />
dieter nafzger,<br />
Katarína Beinrohrová<br />
production<br />
von ah druck aG, sarnen<br />
Circulation<br />
10,000 copies (German) + 2500 copies (English)<br />
Published quarterly<br />
issn 1664-4433<br />
Copyright © 2012<br />
by Erni Management services aG<br />
all rights reserved.
www.erni-consultants.com<br />
enables & delivers