Whatties and Howies: Informal Metaphors for Scrum Roles

When trying to explain the Scrum roles to either managers outside the Scrum or the newly formed Scrum, here’s a little metaphor I developed early 2015 that might help.

My Story of how Whatties and Howies came about…

My goal as a Scrum Master is to find the fastest way I can get people to grasp any concept and run with it as their own. I am constantly trying to simplify terminology and jargon.  I do this by relating new concepts to things they are already familiar with.

Here’s how I’d explain the Scrum role back to basics:

Mr Product Owner, you do ‘What’ and only What.

Scrum Development Team, together you only do the ‘How’. 

Both roles are expected to make suggestions and collaborate, but the Whattie has the final say as being the accountable for ‘What’ is done and the Howies get the final say on ‘How’ they’re going to do it.

Together we are all Scrummies and we as Scrum team are jointly responsible for the outcome.

How I use Whatties and Howies ..

These metaphors are exaggerated expressions intended to give effect to the impact of the Scrum Roles and to paint a vivid picture of the purpose of the Scrum roles.   It helps people to know who to go to with their query and to better appreciate that neither is ‘in charge’ of the other and both roles collaborate together.

Use Whatties & Howies to Focus on Responsibilities

I use these names to correct behaviours that don’t stick the roles.  Essentially to give focus to the purpose of their role.  For example, I had a person from a traditional project management background that took on the role of Product Owner.  Being a PM he was used to dictating both what and how –  with the how’s typically in minute detail.  In the first few Sprints he kept picking up what I perceived as small technical nuances in preferred delivery techniques and asking me to correct the Howies to do it his way.
I asked the Product Owner: “Are you a Whattie or a Howie?” 

He said: A Whattie

To which as a Scrum Master I replied:  “Thanks for your suggestion, Mr Product Owner.   But I need you to spend all your energy building us a Product Backlog that has user stories to the Definition of Ready two sprints in advance.  Getting the funnel or pipeline full of right-sized and prioritised user stories is many magnitudes more important to the success of this team than nit picking at the How’s.  I have no doubt that the things you suggest are of value.  But if you don’t give us the What, seen as that is your primary role on this team, then we are doomed.  In traditional project management terms, right now if I had to do a risk register, I’d put your role as a red traffic light and our biggest risk.  Your role is so critical  and I need you to focus on What and just the What. So how about you master the What and when you’ve got a perfectly refined backlog that’s on track to meet project objectives to the definition of Ready, let’s talk.”

After this, he smiled and said “You’re right” as he rubbed the Howie instructions he was detailing off the whiteboard and turned to focus on the meeting.  Interestingly enough, we never had that conversation again as I think he got the importance of focussing on What.

Use Whatties & Howies to Identify People in A Role

I also use it when I’m setting up appointments in a shared calendar, I’ll say “Whatties stand-up”.  If I’m setting up a coaching session I’ll let them know which role/s need to attend.

I use it in Microsoft Exchange’s Active Directory distribution lists like #Cloud Howies where the Cloud is the name of the scrum team  #<projectname> Howies. Once I have this list, it makes meetings or internal communication easier.

It’s also easier for dyslexic people like me when I accidentally abbreviated the Scrum Development Team SDT to ‘STD’.  Understandably people were most offended by being associated with the most common use of this acronym Sexually Transmitted Diseases.

It’s also really, really handy if you have two Scrum Development Team’s working off the one backlog.  For example, when I have two Scrum Development Teams where they self-named themselves Spark and Atomic, the Active Directory distribution list became

#Cloud Atomic Howies  and #Cloud Sparks Howies  using the format #<projectname> <scrumteam> Howies.

Use Whatties & Howies to Help Non-Scrum to Get it

And the piece de resistance (aka: my best use) is when I’m introducing the roles to people outside the Scrum in visual management.

I want to make it really simple for people outside the Scrum who haven’t had any Scrum training to understand who’s doing what so they know which person/s they should go to.  When I bring key stakeholders into a project room and walk them through the walls, I use the Whattie and Howie terms so they ‘get it’ fast.

You would hear me say something like this …

See this wall over here, this is What we are going to be doing. From our highest priority to our lowest priority.  It’s called our Product Backlog.  The one person that is exclusively responsible for ‘What’ we do on this wall is the Product Owner.  If you have any suggestions on What you want to see, you’re wasting your oxygen speaking with anyone else on the team or outside the team including the business sponsor, take it straight to the Whattie that owns the product. 

Walking to another wall in the project room, you’ll hear me say something like this…

See this wall over here, this is the wall that tells you How we are doing the work for this fortnight.  We call it the Sprint Backlog. These people over here, the Scrum Development Team are all Howies.  They manage their own ‘How’ wall.  So if you have a problem with any part of How we’re doing something, go direct to the source of the Howies, because only they are the only ones that can fix it. The Product Owner is not their manager, he is their equal and we have strict roles in a flat team structure.

If you don’t know if your issue is about the ‘What’ or ‘How’ then see me as the Scrum Master and I’ll forward it on.

How I do NOT to use Whatties and Howies metaphors

I don’t use Whatties and Howies formally on any position description, job description or organisational chart as this dilutes the real and correct Scrum Roles as given in the Scrum Framework.

Hope this helps Scrum Masters going into organisations that are very new to Scrum and they have a lot of key stakeholders to get up to speed quickly on who does what.