Making Tea and the Scrum Framework

Making Tea and the Scrum Framework

It is often said that Scrum is easy to learn and hard to master and one of the most frequent retorts that I hear during discussion is “Scrum is a framework not a methodology’.  Sadly, it’s often said in a tone that ends the discussion in a very condescending way.

I thought I’d explore a little more about the meaning of this and try to find a way to help anyone struggling with understanding the important differences.

In order to help us think, let’s have a cup of tea.

I hope we can all agree that everyone makes tea differently. I recognise that I am probably a bit of an outlier as I like hot water, a bag of cinnamon and a little honey.  Some of you may be reeling in horror at that concoction but as I’ve never been able to stand even the smell of ‘normal’ tea, that’s the way I do it and I won’t be changing any time soon.

So, does my cinnamon infusion constitute ‘tea’?  What is required for a drink to be classed as tea?  For anyone who watches Bear Grylls as he boils pond water and adds any random leaves that come to hand, I always think my option is somewhat refined comparatively.  For reference there are many different definitions in dictionaries or online, e.g.: “(a drink made by pouring hot water onto) dried and cut leaves and sometimes flowers, especially the leaves of the tea plant” from the Cambridge Dictionary.

If we looked at 100 different people or cultures, we would likely find 101 different methods for the creation of a drink they refer to as ‘tea’, but they must have something in common for that moniker to be attached.

If we accept that hot water and something to infuse in that water, is the simplest common ground then that’s the framework for making tea – no more no less.  The addition of milk, sugar or anything else are details you have settled on after experimentation and form part of your personal method.  It’s a topic that stirs the passion of many and people will defend their personal methodology for making tea to their dying day.  It works for them, and you can’t argue with their preference – you may suggest possible improvements but whether they are prepared to experiment is always their choice.

Scrum is no different.  As a framework, it is set of ideas of ‘good’ things to do when managing product development. This includes agreeing something you want to achieve (a goal), working out a plan to achieve it (sprint backlog) and making as start.  Once you’ve started, it’s useful to make sure everyone is synchronised, and aware of any important new information affecting progress towards the goal, daily as a minimum.  At the end of the agreed time (sprint length), you can review what you have achieved, with relevant stakeholders, to help you consider what to do next.  Scrum also recommends that you think about how you achieved what you did and perhaps identify an improvement for the next iteration (retrospective).

Scrum doesn’t tell you how to plan, it doesn’t say that you need to estimate or use story points or even that you should define your goals as user stories.  It doesn’t say you have to ask 3 questions of everyone in the team every day or that you must employ automated testing tools. These are all examples of commonly used methods (just like milk and sugar in tea) but they are not part of the framework.

We can both make tea in our own way – I won’t criticise yours but please don’t pull faces when you look at mine.  Many people use Scrum and find it useful.  It’s not the only route to agility and it won’t give you all the answers but as a framework it is there for support. Applying the elements within Scrum and experimenting within your own environment, can help you identify your own recipe for a successful brew.

Related posts

Leave a Reply