Shakespeare’s Macbeth and agile product management
-
Share:
-
-
-
Yesterday I watched Macbeth, a magnificent movie based on the cognominal tragedy by Shakespeare’s. In short it is about “Macbeth, the Thane of Glamis, who receives a prophecy from a trio of witches that one day he will become King of Scotland. Consumed by ambition and spurred to action by his wife, Macbeth murders his king and takes the throne for himself”. Besides the fact that it is a beautiful movie (I really enjoyed it), I think that we can learn something about Agile product management from it.
(If you have not read the play, nor seen the movie beware — there are a couple of spoilers here.)
The prophecy received by Macbeth claims that “none of woman born shall harm Macbeth”. This makes him feel invulnerable, and in the end he fights with Macduff, confident in the victory. But Macduff wins this fight and kills Macbeth because:
“Despair thy charm;
And let the angel whom thou still hast served
Tell thee, Macduff was from his mother’s womb
Untimely ripp’d.”
So what can an agile team learn from this story? It’s the hidden assumptions that led to misinterpretation of a prophecy and ultimately to Macbeth’s death. And though Agile does not demand that we shall kill someone to make a great product, it has a couple of practices to deal with hidden assumptions.
First is the user story itself. User stories encourage open discussion between team and a product owner, and that discussion helps the team to better understand the story, the product as a whole, and helps to eliminate some of the hidden assumptions a team might have about a story.
User stories answer 3 key questions: who are we building this for, what are we building and why are we building this. Answering them will help a team understand a requirement and it’s broader context. This helps it work appropriately.
Secondly, it is the Definition of Done and Acceptance Criteria. This two are critical to expectations management — just because they display all the assumptions to stakeholders: how much will be done, how a system should behave, what are the criteria on which it will be accepted and what quality to expect. All of these are essential to gain mutual understanding of a User story by all stakeholders.
And last, but not least is a User Story estimation process. As Dean Leffingwell writes in his book “Agile Software Requirements”
“One of the primary benefits of estimating user stories is not simply to derive a precise size but rather to draw out any hidden assumptions and missing acceptance criteria to clarify a team’s shared understanding of the story. Thus, the conversation surrounding the estimation process is as (or more) important than the actual estimate”.
This returns us to the one of the user stories goals — to encourage a conversation around them.
So if Macbeth was familiar with user stories, how could the prophecy be expressed as an agile requirement?
Be bloody, bold, and resolute; laugh to scorn
The power of man, for none of woman born
Shall harm Macbeth.
User story: As a tyrant I want to be invulnerable to my enemies so that I can continue commiting atrocities without fear of revenge.
Scenario: Someone wants to harm the tyrant.
GIVEN There is a tyrant
AND he kills someone’s family
AND the victim seeks revenge
AND the victim was born by a woman through a natural childbirth
WHEN a victim tries to harm a tyrant
THEN he can do no harm to a tyrant
If Macbeth had this as a prophecy, his story could be very different.
OK, I see that this is a really stretched example, but this does not discards the initial premise: hidden assumptions can be deadly dangerous for any endeavor (including tyranny and product development). So working with assumptions and especially eliminating the hidden ones is one of the keys to success. Agile has several tools to address the hidden assumptions: user stories, definition of “done” and acceptance criteria and estimation. And all these tools encourage conversations that help to display all the assumptions.