Scrum starts at Product management
In the past few years I have been implementing scrum from scratch twice. This is the reason why I have not been writing too much lately. Too busy getting scrum going. Both times it turned out that there was not much resistance or big hurdles. Both times the teams had to turn around from vague waterfall approach.
This makes me wonder. Why are there no major battles? Until tonight I could not really give an answer to that. But at a scrum meeting I had the pleasure to talk with an development manager of a big insurance company explaining me his difficulties of implementing Scrum from out of development while product managers did not buy in. That was pain… While I am thinking about tuning after 5 sprints, he was struggling to get requirements discussed a year after introduction. He is a long way from his hyper performing team goal. And I am not even taking the culture of the Insurance business in account here.
So, I guess, the difference is the support or even drive from out of Product Management. Of course without sitting on the chair of the Development Manager or Scrum Master. But why does that make such a difference? I think you have to look at the traditional role of the Product Manager to find the answer.
Don’t be evil…
For the average development department the product manager is evil. It is the guy that want the impossible functional, in a unrealistic timeframe. And since everything is put into a 100 page requirements doc, these cannot be discussed anymore. It has been signed off, we can’t change it!
When your Product Manager turns into a product owner the role changes completely. Let’s start at the requirements. No more 100 pages of requirements, but stories. And since stories are invitations to discussion suddenly the requirements are things an entire team can start thinking about. You have a platform that involves the developers in creating a solution. They are not building the solution, they are now part of coming up with a solution.
Another element is the fact that you deliver functionality every sprint. Due to the fact that each sprint you want to build value, every sprint demo the developers will show things that are relevant an tangible. It suddenly makes clear that what these guys are doing makes sense, that they are actually building value.
No battle
There is no developer on this world that does not want this. If Product Management supports transition to Scrum, you have won halve of the battle.. or maybe there was no battle at all, you just made a transition. If a team is confronted with an involved Product Owner, working as a developer becomes fun.
I am sure that the role of Product Owner can make the difference in making your transition a success. Also I believe that you rather should be a Product Owner then a Product manager. Since it gives you full control on creating successful products, instead of successful requirement documents.
Agile Product Owners 
How do you apply this to a organisation where there is multiple scrum teams working on the same system?
I do think that this does not matter. As long as there is a buy in of both product managers and teams.
If you start for the first time, I would single out a nice project to demo that Scrum really works. So do take a risky project.
But multiple team should not be an issue. If each team has a their own scrum master, make sure there is a Scrum of Scrum, and make sure the PO always joins this Scrum of Scrum.
How about the reverse situation: a Development Manager who doesn’t accept the role of Product Owner, believing it to be unnecessary since he’s in communication with business managers directly?
That sounds like a pain.. not acknowledging the method is one.. but not acknowledging the role completely sounds like mission impossible.
If there are multiple business managers (customers) there is a fair chance that they want different things and even contradicting things. Find that, and bring a solution… or get the development manager fired… 🙂
Great article, thanks for sharing!
We’re having exactly these challenges while implementing scrum.
But even before that we’ve found out that even some developers are not ready to work with scrum, specially when it comes to be involved into product definition.
Challenge was to develop certain product focus skills within team to look on a product not from only tech perspective , but also from business perspective , which often related to a boring reality of KPIs, quarter targets and obligations.
Agile enables teams to achieve much more, but also requires much more.
How long do you think typical transition period from waterfall to agile takes place ? Not only in terms of methodology , but also in terms of team mindset ?
Thanks
In many business contexts, the product manager is an external-facing role who must partner with an internal product owner, who actually sits with engineering. It’s very hard to do both at the same time (well) in many organizations–it’s hard to fully represent the customer and understand problems in full while being “constantly available for questions” as the product owner role is described in much of the agile orthodoxy.
This is exactly the thing that makes being product manager a difficult job. You have to do both. You have to master both. Splitting it up brings back the alienating situation of the past. Looking at the sprints results you have to be able to feel as a user. You have to be able to impersonate users you have been meeting in real live. External Product manager sounds more like a sales guy or a evengalist… But Product Manager is on top of that the one that creates it.