SCRUM is good for managers but bad for developers

You’ve been using the SCRUM methodology for a while now. At least, some version of it. It involves daily stand-up meetings where you have the opportunity to half-brag or half-complain about yesterday. And you can listen to others on your team do the same.

Let me tell you about yesterday #imawesome

Thank God for SCRUM, otherwise you’d have no idea what feature set will be in the demo next week, right? Without SCRUM, it would impossible to organize a set of features into a cohesive group. Without SCRUM, the entire development and design team would surely crumble into a pile of rudderless children and probably spend their time picking boogers or writing blog posts instead of working (wink).

SCRUM is good for project managers and bad for developers.

You’re doing it wrong.

Unless you’re a manager, knowing a deadline for a large sub-set of features the entire team is working on is kind if useless. In fact, it’s harmful because it’s distracting. By worrying about the entire sprint’s worth of items, you’re taking precious attention away from your work. By extension, if you (the developer) have to think about any subset of the sprints’ worth of tasks, that’s a distraction.

But, I’m a project manager

If you’re a project manager, then it’s your job to know this stuff anyways, regardless of how the team’s tasks are organized. There’s no need to pollute the team’s attention by shifting focus on the entire sprint (especially on the daily).

There’s a better way, it’s called KanBan.

Kanban let’s you stay focused on building the one piece you’re tasked with and building making it the most awesome version of that thing it can possibly be. It does this by removing those opportunities for distractions and making the project leads accountable. Responsibility for the project is still shared amongst the team, but it’s delegated responsibility. The managers worry about the “why” & “what” questions, the developers and designers worry about the details of “how.”

There. Everything is in it’s right place and every single person knows exactly what they’re supposed to be doing.

Rules, man.

Kanban rules are simple.

There’s Only Two

Rule #1: One in, one out

Each developer works on only one task at a time. This means project managers feed them features and tasks as the project matures. A developer never has to worry about a pile of tasks in a “To Do” queue.

At last, you’re free to truly focus on the thing your building, which means you build faster, more modularly, and just plain better.

Rule #2: No Deadlines

Yeah it did.

Yeah, I know. This seems like a fairy tale, right?

What I mean is, even if the project manager has their own deadlines or projections, the development team isn’t bothered with them. As a developer working in Kanban, I never see any deadlines nor am I asked to estimate anything in any absolute sense.

I might say, “Hey this will take longer compared to that,” but I’m not promising that a task will get done before a certain date. Ever.

How is this possible?

If the project manager creates tasks that are roughly the same size, and the developer works on only one thing at a time, it’s rather easy to devise their velocity. You could use this velocity to determine an approximate timeline if you desired.

This is really not much different than what you probably normally do, except you never need to bother a developer about it. We’re terrible at estimating anyways, so why not take us out of the equation and use real data to determine your estimated dates?

Consistency is Paramount

My colleague (a product owner) offered a substantially important comment outlining the importance of consistency from a manager’s perspective:

This method requires developers to BE CONSISTENT in your personal work flow as well as the team’s work flow. Consistency lets managers predict, because (within reason) you guys do things the same way every time.
-Nick Coppolo, SpireMedia

The trade off for not having to wade through the mysterious & illusive world of estimation is that we, as developers, need to be consistent. Our consistency give the powers-that-be the data they need to more-or-less accurately estimate on our behalves.

These estimates are better because:

1. They’re data-driven: There’s no personalities in the mix, no erroneous details or wrong guesses as to scope. There’s your consistent, regular velocity and there’s chunked out tasks to be completed. This reduces what is usually a collaborative cluster-**** to a simple math problem.
2. It leave you along to focus on what you’re good, and hopefully passionate, about: developing. No longer are you force to sit through lengthy client meetings about scope, marketing updates or pie-in-the-sky feature ideas. Leave that for the manager, and they’ll leave you to develop a badass application.

That all there is too it!

It should be noted that this is my experience with Kanban. I’m sure there’s other versions of it’s implementation and other rules you could find that I don’t abide by.

That said, it works super-duper well and you should try it.