Blog & News

Home Sweet Home

What
inspired me to write this post was a tour of a company I’ve recently returned
from. It involved a range of SCRUM training sessions that brought up my
philosophical, if not existential mood ;)

Metaphor of a House

It
is an allegory that I like to quote to make the young agile cadets aware of the
difference between the “agile” approach and the “heavyweight” methods. It also
lets them realise why, despite the simple principles, the application of “agile”
frameworks may be very difficult at the start.

Speaking
of starting: let’s begin with an illustration, where a project turns into a
house. Every “heavyweight” method offers you a single type of a house,
moreover, a fully furnished one. This initially seems fine, yet the problem is
that each piece of furniture has its own place defined once and forever, and
cannot be moved to any other location. Nor can you reject any element of the
furnishing, as this voids your warranty for the entire house ;) As you can
guess, if it was not you but somebody else who furnished the house for you and,
which is worse, did it with no respect for your individual preferences and
needs, your comfort of living in it will drop significantly, in extreme cases
making any sensible existence out of question.

In
turn, agile frameworks offer just the shell and core of your house. It is
designed so that you have maximum flexibility in furnishing it, yet, my dear, that
is now you who have to adjust it to your needs. And living in an unfurnished
flat is tough, at least in a long run :-)

Let’s
now make a reference to SCRUM: you’ve got a framework, and now you’ve got to
make yourself comfortable within it. The adding of new elements/tools/principles
is necessary, and so is changing them at need, and at times even removal of the
ones that are dated or no longer useful. Moreover, all the time you need to
control whether your “ecosystem” built within the SCRUM framework meets your expectations.

Here
is what I believe to be one of the main reasons behind failures while trying to
switch to agile. A beginner team follows the recommendations of, for example, SCRUM
guide, and decides how long a sprint must last, organise SCRUM events, and builds
artefacts. And no more! Let’s remember that SCRUM won’t solve for us even a
single problem that emerges during a project. All it does is to bring such a
problem quickly to the light. Nor would it define or describe a detailed manner
of monitoring the process and/or a precise manner of its improvement. This is
something that many inexperienced teams don’t realise. Individual elements of
the SCRUM begin to chafe uncomfortably, because they reveal certain problems
that need to be addressed. How do team members see this? SCRUM is cool (because
it’s trendy) but it doesn’t fit our
project (because the problems we were not aware of earlier begin to chafe), why
then don’t we remove the element of the framework that exposed the problem? (After
all, isn’t ignoring problems the simplest way of solving them?). On top of
that, let’s put the whine and excuse “This won’t fit, because our project is specific.” And – tah-dam – we’ve got a SCRUM-but.

For
that reason precisely when I do a SCRUM training I start from a lecture (with
examples) on what this agile approach really is about. Before we finish
discussing the subject, I don’t as much as mention a single element of the SCRUM.

So
as not to be high-winded, here are some problems and questions that I have
encountered while we were designing our work within SCRUM framework with
various teams:

Retrospection:

What
tools to use in a retrospection? Most people have a certain idea about a
brainstorm based on good/bad/to-do areas, yet they don’t know that there are
hundreds of other helpful techniques, e.g. timeline, one-word retrospective,
ESVP, 5 × why (to go deeper into the subject, I suggest you read Getting Value out of Agile Retrospectives
and Agile Retrospectives: Making Good
Teams Great)

What
to do to implement the results of a retrospection in practice?

How
to measure the efficiency of actions defined during a retrospection?

…

Daily Scrum:

At
what level of detail should we keep task description?

When
to solve problems reported at the daily scrum?

How
to implement Sprint Backlog?

How
to control the progress of work in a sprint?

How
to plan further works in a sprint?

…

Sprint review:

How
to present increment?

How
to involve “client” efficiently into a review?

Which
subjects to tackle, and which are better left for other events (e.g., Sprint
Planning/Grooming)?

What
to discuss at a Sprint Review, and what to transfer to a Sprint Planning/Grooming?

…

Sprint planning:

How
to build a Sprint backlog effectively?

How
to estimate the volume of tasks?

How
to cooperate with the Product Owner (especially when there is only remote
access to the PO)?

You will find no (direct) answer to
any of these questions in SCRUM guide. Moreover, if anyone gives you a
definitive answer to any of these, don’t trust them as they are the ones who
try to furnish your house according
to their preferences. Obviously, listen
to suggestions, draw inspirations from the experience of others, but always
adjust solutions to your own needs. And never be afraid of experiments that may
end in a failure. This is a constant element of agile approach. Rome wasn’t
built in a day.