Scrum: beware of invisible cows!

Sjoerd Nijland
Serious Scrum
Published in
5 min readMar 24, 2018

--

During a visit to the Mauna Kea Observatories in Hawaii, I was surprised by a road sign that read ‘Beware of Invisible Cows!’.

“Dark colored cows are often invisible in darkness and/or in fog. Use extreme caution!”

In my previous article on ScrumButs (you use Scrum but…) I summed-up some painful (but obvious) defects Scrum Masters encounter in their noble journeys; and this sign often popped-up in my mind and got me thinking:

What are Scrum’s “invisible cows”?

What warning signs can we, Scrum Masters, put up for those who are travelling along similar paths to Scrum?

Now I imagine that if you bump into a huge cow, you might think to yourself:

How the @!$%# did I not see that cow!

So in this article, I will put up some warning signs; in the hope that you will do likewise and not run into invisible Scrum cows.

So BEWARE OF:

Job Requirements.

Some of these big cows are hidden in the job specifications. These signs warn you that you are about to enter an organisation that might not actually want to Scrum:

  • “We are looking for a Scrum Master/Agile Coach/Project Manager.”
  • “You will be leading the transformation of [x] teams to Agile/Scrum methodologies”
  • “You will make sure the team finishes their Sprint on time.”
  • “You will be the team lead for our Design Team, Development team and QA team.”
  • “You will increase the performance/velocity of the team and make sure they meet their commitment.”
  • “You will manage our [insert SILO here] department/team.”
  • “You will report the team’s productivity and efficiency metrics to the (departmental) management team.”
  • “You will manage JIRA.”
  • “You will lead and facilitate [Sprint Zero/Design Sprint/Architecture Runways/Hardening Sprints].”
  • Or any of these 22 Scrum Anti-Patterns you may find in Job Ads.

So, are you really looking for a Scrum Master?

So beware:
It is likely that the organisation posting the vacancy is not aware of those fallacies, or (if they do) they simply don’t care. Then again you could think it might become your job to teach or guide them, but don’t be surprised if all your Scrum evangelising will result in the organisation's management concluding they actually don’t want to Scrum.

Contracts.

So your team is great at Scrum! the PO is involved and gives the team awesome input and feedback from stakeholders and users; the team welcomes changing requirements and is still able to create reliable forecasts; what they deliver works like a charm and feedback is processed fast. WOW AWESOME! (truly)

But hey, the client’s/PO’s management is unhappy because they had been promised [x] features, at [y] date, at [z] rate; “it says it right here in the contract.”

So beware:
The client has been promised all the original unrefined scope, and the team is now expected to deliver all of them anyway. Oh and all the scope changes the PO introduced along the way?! they are now all delivered for free; all because the contract didn’t fit Scrum.

Bugs. Debt. Defects.

So let’s say the team is delivering increments early and frequently. However… the client, stakeholders and users may not be used to this. They might report a lot of ‘bugs’ and expect those to be resolved without taking them into consideration in the forecast. You’ll know if you run into this cow if:

  • There are constant battles and discussion over what might be a ‘bug’ or what is an ‘increment/scope change’.

The [client/PO/stakeholders] often provide feedback such as:

  • “It should have gone without saying that …”
  • “Just one more thing…”
  • “Why is this not…”

The team is often frustrated that:

  • “The story wasn’t specific…”
  • ‘Nobody ever mentioned that…”

As a Scrum Master you might wonder how all this is possible. The team is doing Test Driven Development! by-the-book even! and the Definitions of Done are clear […]

But a lot of cases were not covered because those cases had never been considered.

The Scrum team and Stakeholders get frustrated over these findings, rather than excited about having discovered them early and resolved fast!

So beware: Your team might end up resolving defects/bugs for free and doing overtime, falling back to writing poorly written artefacts; yet without ever satisfying the customer.

Meetups, Open Spaces and Pizza Sessions!

Oh boy. Apparently the organisation you work for doesn’t actually expect you to do your job during the daytime. After all:

  • “Training and coaching should be done in your own time!”
  • “The Scrum events are already a waste of productive time!”
  • “Great you want to introduce clean code standards, why don’t you host a pizza session?”
  • “Can’t you use the retrospective for that?”

Don’t get me wrong. Flexible working hours are great. I frakking love pizza…or sushi…mexican…indian…thai…chinese…klingon. But so do I love training and coaching to be a part of the daily routine.

So beware: Your company or team might not consider training and coaching as part of the daily job/routine. They’ll consider it to be a waste of productive time, or that it will negatively influence the team’s current velocity.

Ticket machines / Jira monkeys

Who really owns the Sprint Backlog at your organisation?

The Development Team works to forecast the functionality that will be developed during the Sprint.” — the official Scrum Guide

Though the Product Owner discusses the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal, selecting (the number of) items should be solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

However, beware! in many organisations, it’s either traditional management or the Product Owner who will insist on what the Development team should be working on, who should be working on what item, when they should be working on it… and when it should be ready.

Tickets are entered in Jira, and the team simply reports on its status through a Kanban board. The Daily Scrum is nothing more than report of ticket statuses.

So beware: Your company might have put up a Scrum facade for appearances; they’ve configured an ‘Agile’ setup in Jira; only to exercise command and control micro-management.

Check out ‘We Scrum but have to use Jira’ on how to kick this ScrumBut.

So what sign will you put up?

Please leave a ‘beware of invisible Scrum cows’ sign in the comments below!

Ready for more More Cows? by John Clopton

Recommended reads:

Liked this article?

Please clap 👏 . and share the article! It means a lot to me!

Reached the Mauna Kea Observatories safely thanks to having been warned about Invisible Cows.
Do you want to write for Serious Scrum or seriously discuss Scrum?

--

--

Sjoerd Nijland
Serious Scrum

Founder Serious Scrum. Scrum Trainer. Join the Road to Mastery.