Please don’t endorse me for Scrum

Ido Ish-Hurwitz
Mar 25, 2016 · 3 min read

“… But there is nothing like the sight of an amputated spirit. There’s no prosthetic for that. You think you’re merely sending this splendid foot soldier back home to Oregon with tail between his legs, but I say you are executing his SOUL!” — Al Pacino, “Scent of a woman”.

Every once in a while I get a software engineer’s CV with “Scrum” listed as one of her skills. Some even have “Scrum Master” as a previous position. After quietly sighing, I disregard that, and continue to evaluate the skills and experience I am looking for — technical skills, programming languages, usage of specific frameworks if relevant, sometimes specific product domains, working with customers, the nature of the organization they worked for, and so on…

Let’s start with what’s great about Scrum— Scrum is agile, and agile is not waterfall.

I would stop here, but to be fair — Scrum makes sure the team does a lot of important things for a healthy project — prioritize, plan, track and review. The accurate recipe Scrum provides an organization dramatically increases the chances of success transitioning from waterfall. (Is anyone still there BTW?)

Oh, and it also attempts to empower the team to do all of that instead of the managers, which is very nice. Do note I used “attempts” and not “succeeds”, and I will explain in a minute.

So where’s the problem ?
The problem is Scrum makes teams spend way too much time and energy on process rather than innovating, focusing on technology, product and customers, and basically getting things done. This translates to reduced productivity and no fun.

Let’s talk about Sprint Planning. It’s a great idea to gather the entire team and understand what it’s supposed to do and who is doing what. But why is the entire team interested in the full breakdown of tasks and their time estimations? It’s not. And it’s not fun. And it’s a waste of time. Keep it in high level, and drill down only to the critical tasks (those that there is a real business commitment for, as example). That will give you 80% of the value in holding such a meeting in 20% of the effort.

And what’s the deal with daily meetings? Do you know anyone that wants to tell everyone what he did yesterday, what he will do today and what’s blocking him? And who wants to hear it? Instead, each developer should know what she is working on and when it is expected more or less, communicate freely with the relevant peers on progress and raise red flags if needed. This will be much more empowering for everyone, while the daily meetings do the exact opposite. Add a weekly meeting and casual chats (open-space anyone?) and you have more than enough in order to keep everyone in sync and see the overall progress. For the critical tasks as I mentioned before — probably worth an extra sync.

Another issue with Scrum is it looks at everything from a very tactical perspective. Indeed the agile way is cutting your feature to working deliverables. Yet when innovating, you need some research, some trial and error, and sometimes the muse. Measuring your progress through tactical goals and daily meetings just doesn’t fit. One may argue you should manage these separately, but the reality is it’s not black and white, and you would like to give the engineers the freedom to explore the right approach even in the “classic” tasks. Again, it’s better to go to that level of details only for critical and urgent tasks.

What about customer support ? If it is critical for the business that your engineering team will be very responsive to customer issues (isn’t it always?), you don’t want to put the engineers in unneeded conflict between their “commitment” to the task and their desire to assist the customer. Once again, trust the engineer to raise a flag if the customer issue takes too much time to resolve, and prioritization is needed. But putting a hard “commitment” and needing to “explain” in the daily meeting why a task is delayed, creates automatically a bias against such a customer “interruption”.

Time to summarize — Don’t put your trust in a strict set of rules and rituals, and please don’t execute your engineers’ souls. Trust your common sense, your team’s common sense and automated tests. Your team will be more empowered, will be more productive and will have much more fun.
And so will you.

  • The writer was endorsed 8 times for Scrum in LinkedIn.

Ido Ish-Hurwitz

Written by

About code and management, but not code management.