Thursday Thought — The reality of certification over experience

The Thursday Thought piece is our semi regular look at the world of software development. Always thought provoking, sometimes strongly worded and created to start a debate. The opinions expressed here and those of the author!

I’ve written before about how I believe certification can be a bad idea. This isn’t to say that I think all certification is bad, but certification that pretends to provide qualification to perform a role over more important needs — such as actual experience OR certification that just seems to be an easy way of making money for the certificate provider is a bad thing, a very bad thing.

You can look at my previous content on certification to see my complaints on the actual process but this post is all about what happens when you hire or have someone with a certificate in a team where the certificate is all they have.

So what is the problem?

I’ve been asked before what my goat is with things like the CSM course and certification and in all honesty I don’t have an issue with the material or the course (Even the fact its just two days). My real bugbear is at the end of it people being able to call themselves certified scrum masters. Because unless you’ve had a few years on the clock I don’t think you can call yourself certified as a scrum master. Which is what really worries me when companies recruiting for an SM put the CSM as a mandatory requirement for being given even an interview — it risks anybody being able to apply! Trust me, I know. I’ve hired them in the past.

So anyway, let me tell you a story of a software department. (Names and details of the company changed to protect the innocent/not so innocent) This department was trying to be agile, but had struggled. They had a huge backlog of work, were focusing on measuring the wrong things, had struggled to release anything of substance for a long time and had a bad vibe about the whole agile thing.

Enter Tom, Tom had been given about 10 different jobs in the space of two years working at this company, none of which had really resulted in anything (Not their fault). So Tom had been put on the CSM course as the CTO of this company felt that they needed to become agile.

Tom had never done any agile work before, never worked in a company using an agile approach to software development or worked with agile teams. But Tom was a good guy, he read up a bit on it, did the two day course and gained the certification so he could proudly say he was a certified scrum master.

Tom comes back to his dev teams and with the help of the senior managers moves to agile using Scrum (There were other options that could have been looked at but Tom had done the CSM where the focus is very much on Scrum). He introduces the typical ceremonies around Scrum and applies this religiously — after all this is what the course said good teams should be doing.

The problems start almost immediately. Stand-ups are stale, lose focus quickly, people become disinterested rapidly and some stop attending, struggling to see why they have to stand at a board each day and tell everyone else what they are doing. Particularly as they don’t work with some of the people who are in their stand up.

Sprint planning becomes a two day event due to the need to estimate the entire backlog of work they have outstanding, despite the fact they have nigh on 200 stories and about 20 epics, everyone is estimated — because the course reinforced the importance of estimating. Tom is just doing what he was taught.

Sprint demos are poorly attended because no one knows what they are. The team are very apprehensive about demoing unfinished work to stakeholders. One senior stakeholder blows up about the fact that the work isn’t finished. Failing to understand what WIP means or the concept of a demo. The team leaves the first one heartbroken that two weeks effort has been demeaned like this. Because no stakeholder engagement has been done prior to changing how the teams worked it means more senior stakeholders start to question why the team aren’t working on the stuff they need. The SM doesn’t know how to deal with this.

Retrospectives are stale almost immediately with Lean Coffee being the ‘go-to’ technique, the same questions are asked, the teams switch off, wondering why they need to spend an hour together to talk about stuff they failed to do and worried to talk because the CTO has plopped himself down in the corner of the room whilst they hold the retro.

People start to question the SM on the point of the ceremonies and how its taking them away from doing the actual work the senior stakeholders told them wasn’t good enough in the demo. The SM is ill-prepared for these conversations — it wasn’t really covered in the course material nor was dealing with senior stakeholders with differing priorities.

People in some of the teams become openly hostile to the SM asking them how they are getting on and what impediments are preventing them getting the agreed work done. They feel micro-managed. The SM struggles with being a servant leader because the course covered it but didn’t really cover how to use things like emotional intelligence, active listening or be able to spot some of the now very obvious dysfunctions in the teams.

But the SM is a good guy, he is trying his hardest to make this work, but the material he received from the course isn’t really covering the real-life situations he is now facing in the teams.

3 sprints go by. The teams get some minimal deliveries done but find they have taken in far too much work. The SM struggles to get them to understand the importance of not over committing to the work and how to story split, story map or to pair on the work, because some of this isn’t covered in the course and because there is a gulf between reading about it and putting it into practice with a team of developers who all have the best opinion on how to chop it up.

One of the teams calls an emergency meeting with the senior management team and say they can’t work with the SM anymore. They are tired of all of the meetings, tired of being shot to pieces by senior stakeholders who want to see actual completed work, tired of the deadlines and having to work long hours to meet all their commitments.

One Software Engineer hands in their notice. In their exit interview they point to just feeling like a cog in a machine and constantly having to justify their existence to others.

The other team starts practicing elements of XP and Kanban, the SM doesn’t really know how to help them with this. Further creating a divide between the SM and the other team. This team decides to bin a bunch of the ceremonies. Their Kanban board has no WIP limit, no sense of prioritized work and expedite requests from the support team come in daily, pushing the work they are wanting to do further down the list. Frequent context switching happens hourly as the next emergency request comes from the support team.

The SM and Hof Software go for a coffee and have a heart to heart. The Hof Software likes Tom. He is a good guy that’s been dragged from one position to another. He has done everything that’s been asked of him and worked his arse off to make a go of it but he has had enough. The Hof Software can tell he is exhausted. The SM hands in his notice — he doesn’t even have a job to go to but just needs to get away from the atmosphere he in part has created (Not intentionally).

At the end of the 4th sprint the existing approach is abandoned and the Hof Software starts from scratch. Two members of staff have left the company. Rumors of 3–4 more actively looking for other jobs outside the company are rife in the team and the general perception is that agile is a joke and should not be used here because it just stitches us up in front of management.

To recover that situation took the best part of 12 months and even at the end of it there were one or two who still had a very mistrusting view of agile. That was 12 months pain that could have been avoided with an SM who had more than a certificate. And this is absolutely not about shooting the SM. This SM had worked their backside off to make a success of this but a 2 day course and some material about being a Scrum Master is little preparation for dealing with actual teams with actual problems.

Now who was at fault here?

Tom? The CTO? The company? The Hof Software? The teams? Or a certification body that produces a two day course and hands out a certificate telling someone they are qualified after a multiple choice quiz to support real people in real teams facing real problems?

I know who I think is at fault and it certainly wasn’t the scrum master.

How to solve this?

The bodies that hand these certificates out like confetti need to take a good long look at themselves and do a bit of introspection. Are you more interested in helping the community thrive? Or are you more interested in helping the community shoot itself in the foot and make a quick buck off the back of it?

Because these courses do not and never will in their existing form cover the situations I describe above. They don’t cover off the huge amount of supporting frameworks, team culture, anti-patterns, smells, dysfunctions, cross company demands and people just not getting it that a real Scrum Master has to deal with.

The description of a scrum master as a shield is apt. But it isn’t just to protect the team from outside interference, sometimes (And I believe far more importantly) it’s to protect the team from themselves.

I would much prefer these courses were renamed ‘An introduction to Scrum Mastery’ and at the end of it you earn credits on the way to becoming a certified SM.

And it isn’t just the providers of these courses I have a dim view of. Its us as employers who put a focus on certification rather than miles covered. Ask yourself again, given just the one example I gave above (I have plenty more), would you rather have hired an SM who ticked the box of having the certificate but had no real world experience OR would you hire the person who has no certificates but has worked with teams in an agile environment for 5–10 years? I can tell you with confidence which one will cause more damage to your teams.

This isn’t about shutting out newly qualified SM’s either.

Its about making sure we are all prepared for the situations you are actually going to face rather than the happy-land world described in course material. How do you deal with a CTO/CIO/CEO demanding to know why you showed them this half finished piece of shit the team just spent 2 weeks on? Or the Product Owner that just doesn’t realize where their remit ends and the SM’s starts and keeps popping up to have ‘a chat’ with individual members of the team to bypass you?

Because those are potentially the types of conversations you will have. Being prepared for them is half the battle. Waving a certificate around is going to count for very little when the proverbial hits the fan. We need to better prepare our SM’s for the real scenarios they will face and give them training and ongoing support to make sure they can make the best of their roles. You cannot do this from a 2 day course.

I would love to see a group of us work together collaboratively to produce a set of material and courses that actually help Scrum Masters (And Agile Coaches) get their foot in the door, but more importantly provide an ongoing support mechanism with frequent inspection of what they have learnt and evidence of them putting it into practice. If anyone would like to help kick this off then let me know — and it must be a not for profit function to demonstrate that as a community we can do better without treating it as a get rich quick scheme.

Its time course providers got down off the high horse and joined us in the real world and tried to make this community better trusted and better equipped. Right now you’re making everyone’s jobs harder.