Iteration: inspect, adapt, play
The importance of iteration in Scrum cannot be overemphasised. But why do we put such weight on the idea of repeating stuff?
One major reason why Scrum is more effective than other (for want of a better term) ‘planning systems’ is that it strives to be empirical. Perhaps the simplest way to explain empiricism is to contrast it against the main alternative, which (very roughly) is rationalism. “Rationalism is the viewpoint that knowledge mostly comes from intellectual reasoning, and empiricism is the viewpoint that knowledge mostly comes from using your senses to observe the world.” So, Home Scrum seeks to be rooted more in the reality of our experience than in imagination. This is a big deal, because all forms of planning are by definition an act of imagining the future. So how can Scrum still help us plan for the future while staying based in empiricism?
Making a decent prediction of what will happen in the future is an incredibly difficult task for any human, let alone one with some kind of impairment to their executive functioning. In fact, we can be pretty safe when we say that trying to imagine and anticipate all the steps and obstacles involved in achieving a goal is going to be a waste of time. Instead, if we stick to the principles of empiricism and the scientific method, we can turn our goals in life into a series of small experiments. The results from these experiments can guide us in what we decide to try next; we can adjust our goals based on real outcomes, and this will lead to a much greater chance of success and satisfaction in all our endeavours.
So here are some tips for how to stay attached to reality while coming up with your goals and plans. Your estimations will still be off, but at least you will have kept adjusting for reality throughout the process.
The importance of iteration (Inspect and Adapt)
Scrum, more than anything, is a way to make progressing towards your goals more iterative. This means that you can adapt the way that you’re trying to get to your goal (and the goals themselves) based on the feedback from the reality of your situation.
Iteration is defined as ‘the repetition of a process.’ Each time a new version of some software is released is an iteration. Scrum teams are supposed to use each iteration as a chance to inspect and adapt their processes before the next repetition, so they can gradually align those processes to reality through empirical feedback and become more effective.
The old ‘waterfall’ way of doing things led to basically only one long cycle of iteration, with one version of the product at the end. Scrum breaks this down into many smaller cycles—the sprints. Each sprint is meant to end with a usable ‘Product Increment’ (basically a version of whatever the Scrum team is making) that can be presented to stakeholders for immediate feedback and adjustment in the Sprint Review. This means that the team can continually readjust their original designs based not on what the stakeholders think they want, but on what actually works in reality and has the best outcome for the product’s users.
This principle still works when using Home Scrum. We probably don’t have a ‘product’ we’re making, but we have plenty of goals, and some of them will really benefit from this iterative approach. All you need to do is to remember to apply it. It is not only the process of Scrum itself that the Scrum team is supposed to inspect and adapt; it is what you are trying to achieve as well.
The Minimum Viable Product (MVP)
One of the most powerful concepts I’ve come across in the tech world (originally from Eric Ries’s book The Lean Startup) is the idea of the Minimum Viable Product (MVP). It is the idea that, although your ultimate vision for a product might be highly sophisticated, you can make a version that achieves the same purpose in a much simpler way, and then you might find that you don’t need to carry on to your ultimate goal at all.
A common example is if you’re inventing the first car. You need to distill this into its underlying purpose: what you’re actually doing is inventing a way to go from A to B faster. So, to find the MVP you have to ask yourself, “What is the simplest, easiest version of the goal that would still achieve the same basic purpose to some degree?” In this case, the example answer is: build a scooter. A scooter is just two wheels, a base, and a handle, it doesn’t even require an engine, but it does help you get from A to B faster than you could otherwise.
Once you have the scooter, you can demonstrate it to people and ask, “Is this what you wanted? Is this already enough? What about it would you like to change?” And then you iterate on the design. Perhaps this time you come up with a way to link up the wheels to some pedals instead, so you can make an ‘engine’ from your own feet, and you end up with a bicycle. It’s faster than before, but it’s still not got all the bells and whistles of the original imagined design.
And the idea is that you keep iterating like this until you have gone as far as you need towards your purpose, but in the process you might have gone a long way away from the solution you originally imagined as your goal. In this example, perhaps you would end up with a motorbike instead of a car, because you realised through using the various prototypes that you didn’t actually need to accommodate passengers, and a motorbike achieves all the need for speed you were looking for.
This approach works particularly well with coding and software, since it’s exactly the kind of thing which you can build a bare-bones version of and then keep adding to without throwing everything out and starting again. There are many goals where this approach wouldn’t work as well; for instance, if you’re aiming to landscape your garden, you don’t really want to pay to do that over and over again until it’s just right. But still, there are elements of this approach and thought process that could be applied. You could at least draw out lots of different designs to act as ‘prototypes’ that all the garden users can give feedback on. You could try rearranging the movable elements in your garden to approximate these designs in the actual space, to give yourself the best idea of how it feels in real life. You might find that it doesn’t fit together in quite the way you thought it would, and you can iterate at this design/prototype level until you feel comfortable with calling in the landscapers and making it permanent.
Thinking in this way can be pretty powerful and interesting, but a common confusion about MVPs is to get stuck in thinking that it only applies to a new product, and then only the first release of that product. Perhaps a more useful way to apply the idea of an MVP is to make sure that every Sprint Goal results in some measurable improvement in the outcomes experienced by the users of the product—or in Home Scrum, for the Scrum team.
This leads us nicely into a more philosophical topic: being playful. In the Western world at least, all of us are socialised into more-or-less completely giving up play by the time we become adults. In fact, with the pressure we now put on teenagers (and even young children) in schools to pass exam after exam, that ideal of becoming serious all the time is being enforced earlier and earlier. Yet without play, adults feel a “lack of vital life engagement; diminished optimism; stuck-in-a-rut feeling about life with little curiosity or exploratory imagination to alter their situation; [and a] predilection to escapist temporary fixes…alcohol, excessive exercise, (or other compulsions).”
I have suffered from a life with not enough play. Somehow I got it into my head at a very early age that the best thing to do was to act ‘mature’ and follow all the teachers’ rules. It won me a lot of praise and a defined identity of ‘overachiever’ to which I could cling, but it left very little time for free-form, unstructured play. Mostly play came in the form of guilty escapism, like obsessively reading a novel through the night or playing on the Sims, which didn’t fit into my packed schedule and always felt like procrastination rather than play. Even now, when Francis suggests a spontaneous, enjoyable activity, like going to meet up with my baby niece, I often feel a surge of panic about interrupting the work I’m meant to be getting done (in that case, writing this blog). Luckily, I pushed past the panic and went anyway, and felt much better for it.
So giving ourselves permission to play around as adults can feel rather difficult, and often quite emotional. We may feel irrationally reluctant to do anything vaguely silly. Our ego is always asking, ‘What does this say about me?’ This question is precisely how we build up the story of our self, of who we are, but it can be a major stifling force when it comes to exploring any neglected aspects of ourselves and our desires.
The eminent couples counsellor Esther Perel states that play connects us “to our creativity and problem-solving skills”, and can foster a sense of intimacy between people. She also says that “humour [is] a saving grace in […] relationships.” Couples who make it for the long haul find playful ways to tackle their problems together and maintain a sense of humour towards each other. Francis and I have found that Home Scrum really helps to facilitate that. The Sprint Retrospective gives us a space to brainstorm for ways to solve our problems in creative ways, in fun ways. And by playing around like this, we also remind ourselves not to take life too seriously. You can see some examples of silly stuff we have added to our Home Scrum system in my post so about our burn-up games and other gamification. If we clung to the mask of being ‘mature’ and never playful, then every obstacle could become a huge deal and our instinct would be to blame each other for problems or mistakes. By using play, we can stay light-hearted enough to be transparent and open with each other (which are official Scrum principles and values), which directly improves our ability to inspect and adapt our goals and our Home Scrum system.