What Can Artists Teach Scrum Practitioners about Empiricism?

Creativity is unleashed through inspection and adaptation. Let’s uncover how empiricism works in Scrum and in the arts.

Inspection and adaptation are the last two steps of empiricism, where the agility promised by an empirical process unfolds. All three steps live hand in hand: inspection and adaptation only make sense if preceded by transparency, similarly, transparency holds little value in itself, unless it is followed by the other two.

Inspecta-what? Adapta-huh?

Inspection means examining something closely — studying, scrutinising it with the intention of assessing or evaluating its condition or to discover any of its defects or shortcomings. (I really love the richness of the English language: the synonyms of this word include: going over with a fine-tooth comb as well as the informal giving something a look-see. Strangely enough, for me this phrase summarises best what inspection is: to look at something with the purpose of seeing it for what it is.)

Adaptation means modifying or changing something to ensure it is adjusted to new conditions. I can’t hold back my linguist self to share the origin of this word: adaptare (Latin) is made up of two parts: ad-aptare where ad- means ‘towards’ and aptus meaning ‘suitable’ or ‘fit’ — adaptation essentially is modifying something to make it suitable or fitting (‘apt’) again.

Inspection from a Scrum Perspective

In Scrum, inspection is enabled by transparency and is carried out using the artefacts, which are the empirical representation of the work. The role of the artefacts is to provide transparency for inspection. The three artefacts of Scrum offer an insight into the work observed through the three planes of time:

• The Increment shows us the past of our product. Through the Increment, we can inspect the decisions we have made, all the previous increments we have built, the features we have prioritised — everything about our past journey is bundled in the Increment.
• The Sprint Backlog makes it transparent where we are heading at the present time. We can inspect the goal we are trying to hit and it also creates a shared understanding about what we want to achieve and how.
• The Product Backlog helps cast our eyes into the future. Using this artefact, we can inspect our current priorities and understanding of the upcoming work.

+---------+-----------------+
| Time    | Artefact        |
+=========+=================+
| Past    | Increment       |
+---------+-----------------+
| Present | Sprint Backlog  |
+---------+-----------------+
| Future  | Product Backlog |
+---------+-----------------+

Adaptation — Where the Value Lies

As discussed above, the purpose of transparency is to enable inspection. Similarly, the purpose of inspection is to enable adaptation, because that’s where the value lies in a complex environment — the ability to adapt, to change based on transparent information through deep inspection. The idea and outcome of empiricism, i.e. adaptation, can be directly linked back to the Manifesto:

We have come to value:
Responding to change over following a plan

Adaptation is implied in some of the principles too. In fact, it is pretty easy to follow up most of the principles with a sentence like: and we do this so we can change, pivot or adapt quickly or efficiently.

This is why we prioritise early and continuous delivery of valuable software above anything else. This is why we want business and developers to work together daily. This is why we strive for a culture of empowerment and self-managing teams. Face to face conversation results in clearer requirements which again leads to better adaptation.

In Scrum, adaptation happens when, during inspection, we uncover that the artefacts representing the work are not fit for purpose or if we assume that the “resulting product is unacceptable”. The outcome of the inspection is that the team is able to decide whether the work which we were, are or will be doing is fit for purpose or not, i.e. do we need to adapt or not.

It is the events of Scrum where inspection and adaptation are supposed to happen. The fact that the events happen on a cadence makes it easier for teams to get into the habit of empiricism.

Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts.

The opportunity for inspection and adaptation is lost when teams or some of its members/stakeholders skip a Scrum event. This will negatively impact empiricism and the resulting adaptation, if any, will be suboptimal.

Empiricism Makes Sense

If you think empirical process control is hard, you haven’t tried defined process control in a complex environment. Due to its nature, complexity offers little certainty, but defined process control works in environments where certainty is, well, certain. In a complex space, pre-defined processes, pre-set plans break down because certainty can’t really exist in complexity. Strangely enough, creative professionals who earn their money in the complex space are fully aware of this. Makers, artists, craftspeople, musicians — everyone who is creating something that doesn’t exist yet use empiricism to unleash their creativity and still deliver in time.

Just look at Picasso’s countless drafts whilst creating his masterpiece, the Guernica — just look at the many iterations of the horse, and tell me this dude is not inspecting and adapting in his creative process:

Just look at how the “architecture“ for his work changed during the process of creation and tell me this dude is not living empiricism:

Picasso and other artists and makers leverage empiricism to create something that has not existed before. Even Picasso, a genius, couldn’t have painted Guernica in one single attempt. He needed to create countless drafts and studies of the main figures of his piece ensure that they look just right on the canvas. He created transparency by putting pencil against paper and draw a first draft. He didn’t deliberate, he didn’t do an upfront planning of where everything will be. He created transparency by actually drawing a working increment. He inspected it, and found out where it was lacking compared to his vision. And then he tried again, created transparency, inspected and adapted again.

This is what a shoe-maker does. This is what a blacksmith does. This is what poets, actors and potters do. Empiricism makes sense for them.

Why do we think that the art of creating software is any different? Tell you what: it isn’t. If empirical creative processes are good enough for Picasso, The Beatles and Shakespeare, they are good enough of for our teams of product developers too.

Agree? Disagree? Have different thoughts? Please leave a comment.

Have you found value in this post? Please hit the clap button — and don’t forget to follow scrumtimes or me, the author, to stay in the loop. Thanks!