How to build a palace: Building in iterations is not the same as postponing quality

We all know that in many cases the phrase "we will improve this later" means "we will never improve this".

There is this idiom, “It goes without saying…” which basically means that something is obvious and does not need to be said. I tend to think the heading above is one of those things.

But practice shows that maybe it isn’t, and it needs to be said once in a while.

Sometimes, we all have planning sessions where we say stuff like, “Let’s do the rough implementation now, and we will add unit tests in the next iteration.” or “Let’s put out a quick POC and improve it later.” We also have sprint reviews where we say things like, “It is available on PROD but needs some refactoring—I created a task for it in the backlog. But we can close this one.”

It feels very natural. We are agile; we iterate, and we improve as we go.

All good.

The Metaphor

And now I present to you a picture of a pile of manure, with the author of the pile included:

Now, how do piles of manure come to our world? A cow eats some grass and becomes very introspective and thoughtful after some time. After a couple of minutes of pondering the hard questions of life and the universe, it produces a small pile of cow feces. This cycle then repeats itself. You could say the cow is iteratively building the pile.

However, and this is quite crucial, at no point does the pile of manure transform into a gleaming palace. It stays a pile of manure.

This example gives us our first piece of wisdom:

By producing little shits iteratively, we do not build examples of beautiful architecture. We build piles of shit.

The Second Metaphor

Now, this is a gleaming palace:

How are palaces constructed? Well, you start with a lot of high-quality building blocks, from bricks to pillars and statues, which you produce over and over again and combine to end up with a palace (this is somewhat simplified, but you get the point).

For a good and sturdy palace, not easily conquered by marauding barbarians, it is vital you maintain a standard of quality throughout the process and within every iteration. A single batch of incorrectly baked bricks in the wrong place can cause structural damage with potentially catastrophic consequences.

This gives us our second piece of wisdom:

To build a solid palace, stick to a quality standard every time you deliver a brick.

I think you know where I am going with this. We all know that in many cases, the phrase “we will improve this later” means “we will never improve this.”

Creating a task for fixing technical debt is not the same as fixing the technical debt; however we wanted to wish the opposite. There is a good chance that every time a cow shits, the shit will stay shit and will not get improved later into a brick of gold.

The Point of the Article

This is why we all need to have definitions of done (DOD) and stick to them.

A definition of done protects us from producing little bits of manure and forces us to actually produce proper bricks. It is completely fine not to deliver a palace in one sprint. You can just deliver a brick. But the brick must still be inspected properly, properly manufactured, of the correct shape, density, and material, and baked for the correct time and at the correct temperature.

Or finally, to switch to a software language, it is fine to deliver a single component that does not cover the whole feature set. But the component should still be documented, covered by automated tests, with proper architecture and software design, reviewed, and have monitoring and alerting configured, etc. etc.

What does this mean for your planning sessions?

When discussing any story, it should just never be an option to reduce the estimation by removing parts of the DOD requirements. This brings us to our last piece of wisdom.

You should never compromise on quality when estimating and planning.

At the end of the sprint, you should not close tasks or merge / release code that does not fulfill DOD criteria either. Even if this means missing the release date. This should rarely happen if you take quality into account when estimating, but if it does, it should mean failure. (There is another point here, which is that if our stakeholders only find out we are late with something a day before the sprint ends, we are already in trouble, and there are other problems we need to solve. But that’s a story for another day.)

This is painful. It will create immediate friction and stress. People will be angry.

“Why cannot you release this if just unit tests are missing? This is madness! You can add the tests the day after tomorrow!”

Sometimes, you will add them. But often, you won’t because there will be other priorities and pressures. And the manure pile will keep growing.

At some point, it will become almost impossible to deliver a palace—even if you build a proper brick once in a while, you will still throw it at the existing pile of manure, and it will just become dirty and not usable long-term.

There is going to be no palace at the end of this story.

Just a thoughtful cow.