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:
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
to do to implement the results of a retrospection in practice?
to measure the efficiency of actions defined during a retrospection?
what level of detail should we keep task description?
to solve problems reported at the daily scrum?
to implement Sprint Backlog?
to control the progress of work in a sprint?
to plan further works in a sprint?
to present increment?
to involve “client” efficiently into a review?
subjects to tackle, and which are better left for other events (e.g., Sprint
to discuss at a Sprint Review, and what to transfer to a Sprint Planning/Grooming?
to build a Sprint backlog effectively?
to estimate the volume of tasks?
to cooperate with the Product Owner (especially when there is only remote
access to the PO)?
to calculate and set Velocity?
to divide large Backlog Items into smaller and “valuable” elements in an efficient
manner (see e.g. INVEST principle)
to organise a grooming?
to plan system architecture?
long should grooming last?
far into the future should grooming go?
to discuss at a grooming, and what to move to a Sprint Planning?
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.Author: Piotr Jachimczak / Software Development Manager