Implementing scrum and missing the mark

I have been working with different varieties of scrum for about 6 years now, and I’m not sure that we are focusing on the right things. What are we trying to solve, and who are we trying to preach this new agile gospel to?

A hierarchy of (developer) needs

Like the famous Maslow’s hierarchy of needs, I think that we are looking at much the same thing when it comes to making a working environment for a development team. I believe that this goes pretty much like this:

  1. What am I supposed to be doing?
  2. How am I supposed to do it?
  3. What’s everyone else doing?
  4. How can we get better at doing it?

First and foremost, you want to know what you’re supposed to be doing. As a developer you’ll need some sort of plan, or at least a clear idea of what is the end result.

Secondly, once you actually know what is to be done, you’ll need to know how you are supposed to do it. What are the requirements of the task?

Once you know those things, you can work reasonably efficient, which would give you enough time to help your co-workers out and begin to act as a team, which forms the need to know what they are doing.

Which leads to the final step of wanting to get better at the actual process of doing things.

How scrum is typically implemented

When trying to implement scrum in an organization it’s almost always implemented in the completely opposite direction.

First to be implemented is the daily scrum, because it is easy. Not because people really need it, but because it’s an easy thing to do and programmers need to stand up more in the morning. Secondly, you get to the retrospective. Most teams never get further than this due to organizational intertia or lack of interest.

In my opinion, this is doing it all wrong.

The product owner is the key

The product owner is the key to the entire idea of scrum. Without a proper product owner, you are never going to get things working properly. Look, daily standups and fuzzy retrospectives are nice and all but if the backlog isn’t prioritized you’re going to end up with headless chickens in the development team who does not know what they are going to do next week.

A product owner is not a project manager. And he is absolutely not a developer. And, no, he can’t double as the scrum master. Seriously. And he has about one thing to do, and that is to make sure that there are issues to do each iteration and that they are planned way ahead.

A strong product owner is the buffer between the scrum bubble and the rest of the organization, much like the scrum master is the buffer between the individual developer and the product owner. And yet people keep completely missing the point of the role.

I’m thinking that this is because it’s the most innovative concept that scrum introduces. Most people can imagine the scrum developer with the daily standups and once-per-iteration retrospectives. But the product owner is a new entity, an administrative one that usually doesn’t exist within an organization. So they usually skip it altogether, or completely misrepresents the role by thinking about it as pretty much a renamed project manager.

Barking up the wrong tree

So, why is it that we have Agile conferences filled with people whose primary job is to write code? Why is it that we see the daily standup as the prime vehicle of scrum, where in fact it is a luxury item that only comes into play once you actually know what you are supposed to be doing the next few weeks?

The most common complaint I hear is this:

We the developers try to do scrum, we have our iterations but we still have old-school project managers that doesn’t jive with the methodology. So we only do standups and retrospectives.

Then why bother? If the organization can’t embrace scrum by including one of it’s holy trinity, the scrum master and development team being the other two, why are you trying to fit square pegs in round holes?

If there is one thing I’d like to force into people’s mind it’s this:

You cannot do scrum without a prioritized backlog and a product owner. Everything else does not really matter if you do not have this.

How are your ideas regarding this symbiosis? Do you feel you can really do scrum half-ass and be happy with it? If the rest of the organization is that unwilling to the concept that you can only do it inside of your own little development team with your programming buddies, perhaps it’s time to evolve another system of your own that can actually fit within your organization instead of trying to do everything the opposite way while still maintaining an interface outwards that an old-school organization. I’d love to hear your thoughts.

Tagged , ,

11 thoughts on “Implementing scrum and missing the mark

  1. Good post!
    I’ve been to a lot of preaching to the choir talks and conferences, thinking: “Why the hell isn’t this place full of bosses and would be product owners. The ones who actually need to know about the benefits of these methods.” Once I actually attended a seminar on scrum, in the company of some colleagues and our product owner. The problem there was, besides the fact that he fell asleep halfway, that he commented it as good ideas, but never once acted on those good ideas.

    • Per Dervall says:

      On the same note, why are we doing scrum tracks on developer conferences. It’s strange that we seem to actually prefer preaching to the choir than to redirect our efforts to preaching to the heathens.

    • Per Dervall says:

      I haven’t read this particular one, at least I can’t remember it. But it makes sense, and it’s the same general idea. When doing scrum I often find that focus is set higher up on the pyramid than what the team actually needs.

  2. […] Implementing scrum and missing the mark ( […]

  3. Mike says:

    Yes, I recognize this. I since learned this (in different variations) is often called “scrum, but” which is not necessarily bad, but it should evolve after you try scrum (period). Because then you can evolve, once you know what doesn’t work.

    • Per Dervall says:

      That’s fine, but usually the evolving never goes outside of the development team. Scrum is an organizational wide effort, not something that your devs are doing every morning.

  4. etanol says:

    Dude, you wrote the story of our workplace. We’ve been having this argument lately with our bosses: they want us to take the responsibility of scrum master and product owner, on their company!

    Furthermore, when we finally manage to hardly organise ourselves, they bring it all down with new and to priority new features to implement. Because, obviously, it is always urgent.

    It may be fun to live in the edge, without knowin what you’ll end up doing the very same day. But it gets very tiresome and frustrating after the second week in a row.

  5. joebackward says:

    Right. My organization adopted scrum as a panacea. But the product owner showed up for every other retrospective, and no scrums, because he didn’t have time for that kind of stuff.

    When the project got behind, they hired more …. developers! Brooks’s law (add labor to a late project, it gets later) held true.

    Project failed. Big surprise. Panaceas make me sick.

  6. […] Implementing scrum and missing the mark ( […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: