Skip to content

What Ramsay and Theon can teach us about the Definition of Done

In a recent episode of The Game of Thrones, there is a particularly tense scene between Theon (yes I know, some would say I should call him Reek) and Ramsay the Bastard (yes I know, he has now been made legitimate, but the title is remains appropriate) in which Theon has just revealed some information to Ramsay concerning Xansa.

Ramsay responds by asking Theon to give him his hand.  Now we all know the levels of sadism that Ramsay capable of but more crucially to the scene, Theon knows what Ramsay is capable of.  Hence there is a terrible feeling of suspense whilst we wonder what Ramsay will do to poor old Theon now.

And that’s it.  The scene pans out with Ramsay doing nothing worse than warning Theon that he must always tell him the truth.  Ramsay’’s relationship with Theon has reached the point where the threat alone is enough to scare the living daylights out of him.  The damage has been done.  Theon is acting based on his previous experience of Ramsay.

Obviously this scene sprang to mind when I found myself discussing Definition of Done recently with a scrum team.  This lot were an experienced bunch, knew their way around the block but were newish to agile ways.  On this day the subject of code quality was being discussed – the Definition of Done stated that “code coverage had to be at least 80%” before a story could be said to be completed.  As the current level had dropped below this threshold, a debate started as to exactly what this statement meant.  Did it mean unit tests?  Was it meant to include integration tests?  Did it matter which tools were being used to measure the coverage?

This was all good stuff, a good healthy debate.  But the strange thing was they were discussing the threshold as if it had been imposed on them by some external force.  Now, can you guess who had created the Definition of Done in the first place?  Yes, that’s right – THEY DID.

They eventually got to the bottom of this when they decided to focus on what they as a team thought was the right thing to do.

My take on why they started discussing this as some of externally imposed rule, was that through years of being set rules, requirements and standards by their external stakeholders and seniors, they had been conditioned into thinking that these things were always set by others.  As with Theon, it didn’t matter anymore who set these standards, the developers sub-conciously acted as if someone else had done so.

I’m certainly not blaming these poor wretched beaten up souls any more than I would blame Theon for acting in the way he did.  But the lesson remains.  There are many agile teams out there who are slowly waking up to the wonderful reality of being in control.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *