As a scrum master introducing scrum to an organization, how do avoid also being product owner?

Question

As a scrum master introducing scrum to an organization, how do avoid also being product owner?

problem facts:

• I am working on a project as scrum master.
• Since the organization is new to scrum, I have assumed the role of setting meetings with stakeholders to form their system vision into user stories.
• At present, the stakeholders are not writing user stories.
• At present, our team is guessing what the most important stories should be with light confirmation from stakeholders.

Is there anything more that I can do to move the product owner role away from myself?

Answer 1

It sounds like you're going to have to walk the stakeholders through creating a few user stories first. It also sounds like the stakeholders are perceiving the process as being more complicated than it has to be.

Is the process lightweight enough to encourage the stakeholders to use it, and do the stakeholders have enough confidence in it? Or is it perceived by them as just the newest management flavor of the week?

Answer 2

The first obvious problem is that the project doesn't have a Product Owner (there are stakeholders but no single PO, no single person that can take decision, prioritize things, maximize the ROI of the product). Involve the management if required but this project needs one (and only one) person to play the PO role and support the associated responsibilities.

Second, as a ScrumMaster, one of your responsibilities is to ensure that the Scrum process is used as intended. This doesn't mean you have to do all things yourself, it means you have to teach and help people at applying and using Scrum. So train people on Scrum, organize "story-writing workshops", teach them how to write good stories, support them. But don't do everything yourself, involve people.

Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. --Confucius

Answer 3

I've been told that Scrum is all about exposing problems. Since there's a problem - lack of a Product Owner - your job as Scrum Master is, I think, to see to it that the problem is exposed. One of the best ways to do that might be to let no stories be written, and let everyone understand that nothing happens without stories.

Answer 4

I would advice you to immediately introduce proper Product Owner. You've got a good chunch that you should avoid being PO and SM. Being SM is full time job and you simply won't have to time to being a proper PO for your team.

Ken Schwaber admitted (AFAIR in one of his books) that experienced SM can join these two roles for the brief period of time (while introducing Scrum), but IMO it's additional risk while introducing Scrum and you should avoid it at all cost.

And to answer your question: from my experience with introducing Scrum within organization someone who is/used to be system analyst fits well into role of PO. This kind of person (usually) has skill set which allows her/him effectively prepare Product Backlog and keep it in proper health. They also have good enough communication skills to become "client proxy" between Team and stakeholders and their experience in working on requirements will fit very well in PO role.

From my experience I can also tell that for your new Scrum Team it is crucial to have single point of contact to discuss all doubts regarding Product Backlog items. It really helps Team in their day to day job and boost team's morale.

I would recommend You some reading:

• great article about Product Owner role Being Effective Product
  Owner
• Ken Schawber's book on Scrum Agile Software Development with Scrum

Answer 5

Part of the issue may be in the way Scrum becomes part of the organization. If the organization believes that it will provide real value then, then real change can be affected. If the organization feels it is an IT problem or it is something you are trying to get pushed into the organization without real buy-in you'll find it will be viewed as "Michael's Process".

Your problem in my opinion is the most common and hardest to overcome. How can Scrum be introduced in a transformative way? Who should be the PO and who should be the SM? How do we find a knowledgable PO that is capable enough to understand the process, yet has authority to be the final say to stakeholders?

Those answers in my opinion are not addressed by any Agile process, but are by far the most important.

I believe the answer lies in the psychology of people. How can we transform a culture to affect real change, and not just mask the same old process under a new name? They have to believe in the change and accept the empirical (and transparent) nature of the process. They have to want to change the way they have been used to doing things.

Many times this is hard to accept from someone who is familiar. Bringing in a coach can help with that many times. It may be viewed with more respect and open mind. But, every company is different and will vary because of many factors.

But, let me say this. Not everything needs to change. You don't have to do user stories. If they are comfortable drawing bulleted lists on white boards, snap a picture of it and use that. Later, after some wins in the process come back and revisit changing that. You don't have to educate the stakeholders on using any new process. You need one (or hire a new one) to step into the PO role. You could divide parts of the job. You could have a stake holder responsible for approving the backlog and prioritizing items, while you do the more technical aspects of keeping it groomed and setting meetings. Conversely, you could give some of the Scrummaster's role to another team member. Indeed, finding the super PO will be very hard.