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:
- What am I supposed to be doing?
- How am I supposed to do it?
- What’s everyone else doing?
- 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.