The New Bed

Agile — Re-doing work isn’t a bad thing

Sometimes you’ll have to rework things, that’s fine.

My son needed a new bed, the old one no longer suited his needs. Simple enough, a bed was bought and we spent a few days (his room is quite rammed with stuff):

• clearing out his room
• disassembling his old bed
• replacing old pieces of bed with new pieces of bed
• assembling new bed
• putting 80% of his stuff (re-ramming) back into his room

The pre and post activities of stuff “un and re-ramming” took about a day either side and resulted in crowded corridors and other rooms full of children’s materials. It was hard to walk around the upstairs of the house.

When completed, my son, the stakeholder was very happy. A lovely new bed which met all of his needs.

There was a problem though, he also wanted his room painting. Purple walls — like an Enderman’s eyes from Minecraft.

To do this, we’d have to go through the process of clearing and ramming again. My wife commented,

“oh woe is us, if only we’d waited and not rushed into getting him a new bed, we could have saved all that time and painted the room in tandem, saving us all the time, oh woe oh woe”

* she may have not said it exactly like that

We arranged to go through the same process in the break between Christmas and the New Year.

Our stakeholder objected. He was more than happy with his new bed and wanted time to enjoy things as they were. He didn’t want any more change or disruption to his room. His requirement to have his room painted had changed. He probably still wants it painted, but it can now wait. The new bed was giving him the most value.

Had we planned in a time to paint and change the bed around, we would probably be in the same situation as we were pre-bed. It’s a big job and easy to put off. Nothing would have been done.

But it doesn’t stop here. Surely, we should have planned better? There are lots of thing that we could have done to fully optimise our time.

• New bed
• Paint room
• New carpet
• Window blinds need fixing
• Cupboards no longer fit for purpose
• Shelves need putting up to increase storage
• Desk needs making bigger
• Desk needs more monitors
• Cable tidy for Desk and monitors

This list certainly isn’t exhaustive. But in some software methodologies it’s ideal if it is ;)

Plenty of time will be taken up analysing requirements, making sure that every last edge-case is catered for. With a drop dead end date, you need to be sure that everything is captured. Re-work certainly needs to be avoided. That’s a waste of time.

I’ve just done a small sick in my mouth.

Follow the above guidance and your deliverable will take years. My son would have left home by the time it’s all sorted.

Here’s the other approach.

• Get stuff done
• Get your learns and feedback
• Get more stuff done

Sometimes you’ll have to rework things, that’s fine. As long as you keep the “Get stuff done” part close to your heart.

Where things can go awry in when stakeholders keep changing their requirements. Change is good, but you need to avoid constant tweaks and change that doesn’t provide any value. Measure things, get data.

Software teams can fall victim to rework as well. There’s always things to refactor, architecture to redo. This should be kept in check as well. Again, if this work is stopping you from.. GETTING STUFF DONE, then you should ask yourself some questions.

GET STUFF DONE is better captured by the first principle of the Agile Manifesto.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

And one of the later ones:

Working software is the primary measure of progress.

In reality, I’m not sure if we’ll ever get round to painting my sons room. That one example in itself, completely overshadows the “potential rework” that we would have had to do.

By not worrying about re-work we’ve come across another Agile principle.

Simplicity — the art of maximizing the amount of work not done — is essential.

You only really realise what is truly required after you’ve delivered it.

Thank you for reading this article! Please leave a comment below if you have any questions or feedback.

If you enjoyed this article then please consider buying me a coffee:

Chris Sheldon is a Project Manager for DataArt Ltd. DataArt are a global software engineering firm that takes a uniquely human approach to solving problems.

In his career Chris Sheldon has been a Software Developer, Scrum Master, Development Manager and more. He’s decided that people are harder than process, so this is where his attention is now targeted!

Chris graduated in the UK from Reading University with a degree in Electronic Engineering and Cybernetics.

A bit of a Agile enthusiast, productivity nerd and Wantrepreneur Chris really needs to decide what he wants to do in life and focus.

You can connect with him on LinkedIn, Twitter, Facebook, or by visiting his website, ITsChrisSheldon