This site uses cookies.
By continuing to browse the site,

you are agreeing to our use of cookies.

Blog & News

Go back to article list

Home Sweet Home

25.07.2016

Piotr Jachimczak

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)?
  • How to calculate and set Velocity?

Grooming:

  • How to divide large Backlog Items into smaller and “valuable” elements in an efficient manner (see e.g. INVEST principle)
  • When to organise a grooming?
  • When to plan system architecture?
  • How long should grooming last?
  • How far into the future should grooming go?
  • What 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


Piotrs LinkedIn Profile


Go back to article list