Scrum Roles - an Unsolvable Puzzle?

Anna Forss, TUI Nordic, https://annaforss.wordpress.com/

When I became part of my first Scrum project, I tried reading and participating in the agile community but found that as a "business person", I was rather lonely. Scrum and software development methodology is all too often seen as a problem for "the developers". I’m not a coding person. And yet I develop software. Not by writing code, but by acting product owner in my projects. To enable the successful Scrum project, we need to break down this wall between developers and business folks. We business people must get involved, feel ownership and get ourselves educated. If you want to feel that you’re in control of your Scrum project, get educated and chances are that your view on the word control change in the process.

I sometimes hear that so many Scrum projects fail. That it’s so hard to implement Scrum. Is that true, and if so; why?

It’s my belief that many problems lies in how the different roles are implemented; who is selected to which role, how the roles interact and how people perceive their role (and other’s) in a Scrum project.

For me Scrum is all about how you communicate. And which communication works if the wrong people are discussing the wrong things in the wrong forum? So, you need to get this right to succeed. But what "right" is depends on your organization and the problem you need to solve. This article is built on a number of questions which you need to ask yourself and the other stakeholders in your organization. And you need to find your own answers. I hope I can give you the basis for you to be able to answer these questions for your situation.

The questions are divided into two main chapters. In the first chapter, What is Scrum, I present the basic roles and how they are connected. In the second chapter, But this really didn’t answer my questions, I discuss a number of common questions, especially ones you might ask in an enterprise environment.

What is Scrum?

In this chapter we answer the questions which needs to be answered before the Scrum project begins; or at least very early into the project.

A successful Scrum project is much about understanding what Scrum is and what it’s not. As Ken Schwaber puts it; Scrum does not bring out excellence, it exposes incompetence.

Much of the success lies in the selecting a product owner and a Scrum master. You can perhaps succeed with a Scrum project with the wrong product owner, but I’ve never heard of such a case. Quite the opposite; I have firsthand experience of a Scrum project which fell to pieces within weeks of assigning an unsuitable product owner.

You can perhaps succeed with a less than suitable Scrum master, especially if there is a seasoned Scrum team, but chances that a new Scrum team succeed with a non functional Scrum master is probably slim.

I don’t get wiser by reading on the Internet about Scrum, so what is it?

I’m just a business person and now they are talking about Scrum. I’ve tried to read on the Internet what it I, but I’ve not made it through those long articles and I’m none the wiser.

To give you a short description, Scrum tries to answer the following questions:

• How to decide what to develop?
• Who decides what to build?
• How deliveries are presented?
• How team member keeps each other updated?

Scrum does not specify how you develop and if you look at the list above you can see that Scrum specifies rules for communication during development.

This is the reason why Scrum is most often combined with a more detailed software development methodology like Extreme Programming: since it does not help the developer during the actual programming you might want to add other rules or methods

The Scrum process can be described as the following:

You take the highest prioritized requirements on a regular basis and during a meeting (called the sprint planning meeting) specify which tasks are needed to fill the requirements. After this meeting, during a time boxed period (called a sprint), the team finishes the tasks and keep each other updated during daily 15 minutes meetings (called Daily Scrum). When the sprint comes to the end, the team releases working software and present the result to the stakeholders during a meeting (called the demo or sprint review).

So, here are some principles

 

Sprint planning meeting	During the sprint planning meeting it is decided what is to be accomplished during the sprint. The person who presents the options is the product owner. During the sprint planning meeting, the team takes the highest prioritized feature(s). The team commits to which objectives they are to meet during the sprint. They should select the highest prioritized item(s).
Product owner and product backlog	The product owner has collected a list of the requirements of the system(s). This list is prioritized so that each requirement has a unique priority. This list is called a product backlog.
Sprint	During the sprint, the objectives of the current sprint cannot change without the product owner and the team members accept this. This means that the product owner cannot add or change features without the team accepting the consequences. The product owner can add and change details within the scope of the feature.
Scrum master	The principle is that the Scrum team works undisturbed by external distractions during the sprint. They are self organizing in the sense that they pick their own tasks. This does not mean that they cannot communicate with others. Quite the opposite, team members are welcome to ask stakeholders and users about details, usability and preferred behavior. But outsiders should not themselves confront and disturb individual team members with questions and input. Instead one person is selected to be the one to which an outsider addresses questions. This person is called the Scrum master. The Scrum master is the guardian of the process and protects the team from distractions. The Scrum master does not say what people should do but keeps taps on that things are done.

Suggested readings

• Scrum from the trenches, by Henrik Kniberg
• Agile Software development with Scrum, by Ken Schwaber
• Agile and iterative development, by Craig Larman

But what business is it of mine how Scrum works?

Scrum is a software development methodology, so why should business people like me get educated about how Scrum works? Can’t I just give those code guys my list and let them work that out?

What you don’t understand, you can never control. What you cannot control, you cannot affect. Scrum is about control, but not at a micro level but a strategic level. So, how about it? Do you want to be the one who decides what gets done?

Not everyone involved will read a line of writing about agile or Scrum. Many won’t listen to the podcasts which you recommend or take the classes you want them to. But everyone involved in a Scrum project need to understand the basic principle. So, you must help them. Some will never understand, some will understand but think the rules do not apply to them.

But besides this, you can offer a basic understanding of the process using a simple exercise.

Remember that this exercise is just one example. Depending on the participants, you can use another example.

Start by saying that this is an example of how they can view a Scrum project from a situation, well known to them. And the situation is that the wife comes in and says "We’re having a party!". What does this mean? Depending on who you are you will think different things when you visualize what the party means. Alas, the need for a project vision. You then decide on a product vision, for example that you’re having a family party at home, directed to your parents and the kids in your family and you’re not having anything like the Christmas party.

You then move towards the other steps in the planning phase.

Then, when this is done you can move to the actual project. You can say that there are five days to the actual party. Consider what would happen if you made all the plans today and just expect everything to be done on Friday. Therefore, you make every day a sprint. And this can exemplify some of the issues on one of the sprint planning meetings:

On day two, you get together and see what will be done next. Getting the party hats proved easy but buying the stuff for the case was not completed since the icing was not available at the store. Can we do without the icing or will we remove something else? Doug bought the wrong type of chicken, so here is the question if we should change recipes or if should take the time to go back to the store.

You can discuss the importance of quality, of communication, the ease with which confusion is built and how you can become agile.

The exercise probably takes about an hour and time for discussions afterwards is needed.

Scrum is a method which you can use to make clear the pulse which you have when you develop. It also specifies the rules for who makes the decisions what is to be done and when changes can be made. The principle is that the timeline is divided into time boxed sprints during which you don’t change the priorities.

Try

• Enable that everyone involved can build an understanding of the general process, for example using an exercise as described in this chapter.
• Have the knowledge exercise for managers for both team members and other stakeholders. They will need an understanding of how their teams are affected.

Avoid

• Skipping daily Scrum, sprint planning meetings or sprint review, even if you don’t understand why. At least in the beginning. When you’ve tried using the artifacts, you can perhaps understand better the implications of including or not including.
• Having just one Scrum sponsor on the project. You need multiple people involved, and multiple opinions on how Scrum is to be implemented. If only one person have knowledge and an interest, this becomes an issue for this person
• Reading just one book on Scrum and agile. Different books have so different approach and perspective.

Suggested readings

• Agile Estimating and planning, by Mike Cohn

Should I be the product owner?

What does it mean to be a product owner and who is the most suitable person? I’m the product manager; doesn’t that automatically make me the product owner?

It has often been stated that the product owner is the most difficult role to fill and the single most important reason for project failure.

So who is the product owner? The product owner is

• the one person who ultimately decides what is on the product backlog and
• the one person who sets the priority of all the items on that list.

The product owner is responsible for making sure that all the items on the product backlog can be understood by the team and all the stakeholders. The team needs to know what is to be built and the stakeholders must know where on the list their "stuff" can be found.

The product owner needs to take responsibility for the priority. All the items have their own priority and it’s important that you get the most value for the least cost. It is all about understanding all the requirements. This to understand

• how important an item is
• the difficulty of each item
• the dependencies between items

The product owner needs to be able to explain the needs and requirements to the developer and must be able to give answers to their questions about details. This does not mean that they need to know everything but a good product owner knows who knows.

The product owner needs to be able to make decisions on the spot if this is necessary. And a product owner needs to take responsibility for these decisions.

The product owner should also give some fire and emotions to the team – to make them want to build the stuff!

The product owner should not prioritize the things he likes or which he can benefit from: a product owner must look at the whole picture and all stakeholders and be able to know which brings the most business value to the product.

Perhaps the biggest challenges in the Product Owner role just come from the fact that the many different interest and stakeholders are concentrated into a single role. This is of course not impossible, but challenging! If you are going to act as a product owner, prepare to be involved in conflicts. There is a good chance you’ll be in the middle of lots of conflicts.

Try

• Time box everything from meetings to sprints. When people know the time frames, they most often work more effectively.
• Enable that stakeholders can build an understanding of the general process.
• Have an open product backlog. Let stakeholders and team members have access to the current backlog so they can find out priorities for themselves. This does not mean that people besides you should edit the product backlog but making the information available takes off the burden off information from you.
• Have a product backlog which you keep updated. That means that you should use a format and detail level which you can handle.
• Having an open time or list for input to the product backlog. Sometimes people don’t have time or the knowledge how to post a real change request, bug or something like that. By answering any question within a week you get people to give input which can be very useful, you learn a lot and people get confident in you and the process when they feel that they are heard.
• Estimation poker for business value. Take the stakeholders and give them a list of items. Let them set a value of the relative business value for each item. Gives room for discussions and builds understanding for how planning poker works during time estimations.

Avoid

• Thinking that you don’t have time for being involved in daily routines or skipping sprint review meetings or sprint starts. If you don’t have the time, you are not the right person and someone else will make the decisions.
• If the meeting time is up: call for another meeting and ask yourself why you couldn’t stick to the deadline
• Not making time for real customers. Take the time, but value it against the chance of missing out on important decisions in the team room. This means that if a meeting with the customer is about how to solve an important need which can be accomplished by the product it’s all go. But if the meeting is about general customer care, leave that to the sales people. If your most important task is to participate in general customer meetings, the role should be casted with someone else. If you have a lot of customer knowledge, you will be an important and powerful stakeholder. You will probably have more of a saying if you leave the product owner role to someone else.
• Reading just one book on Scrum and agile. Different books have so different approach and perspective.
• Skipping the product backlog. Good product owners have product backlogs. A product backlog is about having a clear and open strategy for the product. Yes, the product backlog can change, but if you don’t have a product backlog you and others might not know when things change.
• Having unclear rules for prioritization. Don’t just let the guy with the highest salary get his stuff on top of the list but use business value and cost result in a priority
• Skipping calculations of velocity. If you don’t calculate velocity, you don’t know the speed and you cannot give estimations when a stakeholder can start to hope for a wanted feature. By including estimations on an open product backlog and sharing the current velocity, you can avoid a lot of questions concerning "when will I get this".

Suggested readings

• Agile Estimating and planning, by Mike Cohn
• User stories applied, by Mike Cohn
• Confessions of a serial product owner, by Anna Forss

Should I be the Scrum master?

Scrum master, that’s the Scrum term for project manager? Or is the Scrum master the most senior developer?

The Scrum master is not the team member who does the most work. It’s the person who can inspire everyone to do the right job. It’s the person who can communicate to both team members and stakeholders. As with the product owner, the communicative skills are crucial.

The Scrum master should also be the kind of person who has a good "feeling" for how the status is; without having to look at dashboards and backlogs. He should be able to know how things are going.

The Scrum master needs also to be a person who can say yes and no. He is the person who takes responsibility when it comes to delivery and inspires the team to deliver expected value in the form of working software. All team members should feel a sense of responsibility but the Scrum master is responsible.

A Scrum master should not see his role as full time: the best implemented Scrum needs the least of its Scrum master. This means that the Scrum master will probably have to put in a lot of work in the beginning of a Scrum project but this should be a task with declining size. A maximum of one hour a day should be spent and most of that time should be spent on communicating verbally.

Try

• Leave the everyday leading to the team. You don’t manage the team in your role as a product owner. If you think people are doing the wrong stuff or stuff wrong, bring it up with the Scrum master.
• Question if a Scrum master who after a couple of sprints work the tasks of a Scrum master. Either this is not a good Scrum master or there are other issues which must be resolved in the team.
• Pointing at the former project manager and without discussion deciding that this person is now the Scrum master. Instead, read about the traits and select the most suitable person.

Avoid

• Micro management.

Suggested readings

• Scrum from the trenches, by Henrik Kniberg

But this did not really answer my questions…

How do the Scrum master and the product owner work together?

It is often said that the Scrum master role and the product owner role are so important. How does the interaction between the Scrum master and product owner work?

The best product owner and the best Scrum master both work for the same objective: to enable the team to deliver the most business value to the product and the users. But the tools used are not the same. The product owner represents the customer and makes sure that the team can get a feeling for what the users need. To achieve this, the product owner keeps a product backlog and participates in daily work to be able to answer questions.

The Scrum master on his hand makes sure that the contract is kept. He’s the speaking partner for the team but also keeps an eye on the progress so that the product increment really becomes delivered.

In the best implementation of Scrum, the product owner and the Scrum master have a big trust in each other. And the trust is nurtured. The Scrum master does not have to worry about the product owner having made his priorities or being part of the daily work. The product owner does not have to worry about the team doing the right stuff or that impediments are not handled. But the trust must also be in the other’s decision and recommendation. If the Scrum master tells the product owner that a bug cannot be fixed during the sprint, the Scrum master must be trustworthy in that recommendation and the product owner must respect that statement.

The communication between the Scrum master and product owner can work as the glue which binds the business and the team together.

A big risk if the product owner and the Scrum master do not view their work as glue but as a wall: when they control the communication and/or hide things from the team or the business people. This calls for an example.

Scenario A: A customer reports a bug. The product owner talks to the Scrum master who says that the bug cannot be fixed in the sprint so it should be done in an upcoming sprint. The product owner registers the bug on the product backlog, which is open for anyone to see. A developer hears something about a bug and asks the product owner what it’s all about (or checks in the product backlog). The developer learns what there is to know about the bug. The developer does not fix the bug.

Scenario B: A customer reports a bug. The product owner talks to the Scrum master who says that the bug cannot be fixed in the sprint so it should be done in an upcoming sprint. The product owner keeps the bug on his private list, so that it doesn’t become such an issue. A developer hears about the bug but when he asks about it, the Scrum master says it’s no deal and that it’s nothing he should bother about now since it will be fixed later. The developer does not fix the bug.

In none of the cases, the bug was fixed in the sprint, so what was the main difference? Scenario A was built on trust, scenario B on mistrust. What happens in a Scenario B environment is that the developers feel that they are not trusted with information. And if they are not trusted with information, how can they be trusted with the code? It is one thing to force information down someone’s throat, another to make available.

Try

• Trusting others

Avoid

• Thinking that you can hide information.

Suggested readings

• The five disfunctions of a team, by Patrick Lencioni

Can I combine the Scrum master and product owner roles?

I think that product owner and Scrum master seem to be the same thing and doesn’t it make it very complicated to assign different people? Can’t I just keep both roles and be in charge of everything?

If you view these roles as roles, then they can be combined. But it’s not for all to combine roles. A person who combines roles needs to be able to make clear when he’s playing a certain role so that everyone else knows if it’s the product owner or the Scrum master who is talking.

There is also a risk when you combine the product owner role and the Scrum master role: you get a project manager who takes all responsibility and both think and is perceived as the "boss". It is good to take responsibility but this can lessen the others sense of responsibility. To summarize, it’s best to keep the roles separate.

Try

• Keep the roles separate. Even if you are both Scrum master and team member, use some method for making clear when you have a specific role. For example, have different e-mail addresses.

Avoid

• Combined Scrum master and product owner.
• Seeing the product owner and the Scrum master as the most powerful and having managers take these roles without them having the time or the right sentiment for the tasks.

Does Scrum mean that business people can’t talk directly to the developers?

Doesn’t Scrum state that all communication goes to and from the team via the Scrum master and the product owner? Is that really effective?

The product owner gathers and prioritizes the requirements from all the stakeholders. The Scrum master protects and motivates the team to complete the tasks and by doing so, he has a close dialog with the product owner.

But this does not mean that team members should not communicate directly with stakeholders! Encourage team members turning to real customers and users to get input. You have a problem if the stakeholders turn directly to the developers and get their stuff fixed at the expense of other things.

If requirements are changed the product owner must make the final decision and the team should all be in on the changes. The Scrum master is the team representative in these discussions and if he’s not up for a change, the rest of the team should not be involved. If the Scrum master thinks it’s an issue worth bringing up to the team, he takes responsibility for the effect of the diversion.

Try

• Make everyone involved (stakeholders and team members) understand that decisions concerning what should be accomplished are always made by product owner
• Being a good example and put up everything on the product backlog. If you cut corners for what is considered your items anyone can lose belief in the process.
• Reevaluate the roles and how they work. Have an open mind to all the roles. Perhaps you are not the best product owner, even if you have all the traits needed?

Avoid

• Controlling communication. You don’t want to stop the business people from talking to the developers.
• Sticking roles to individuals. See the roles as just roles. The responsibility is individual but only when that person is casted in that role. Things must work even if a person is on vacation or sick. Have plans for these scenarios and let other take the role when this occurs. Superman does not work on your team, or?
• If you get a problem with stakeholders "placing orders" directly to developers, talk to them and explain why this is sub optimizing. Perhaps you need to change how input to the product backlog can be done and people feel that "this is the only way to get things done".

How can I control the team members?

How can I as the product owner contribute to making a team member a part of a successful team?

The team members of a Scrum team should be able to take a high prioritized task from the sprint backlog and complete it. He should ask for help when he gets stuck and reports on his progress. A team member is active during formal and informal meetings so he keeps himself updated.

A team member focuses on the team result, not the individual result. This means that he takes pride in his job but he’s even more pride of the team effort. This means that he’s not the guy who just grabs the fun tasks and ignores helping others. He the guy who drops his task if he’s working on a low priority task and someone is stuck on something with a higher priority.

To help a team member become this excellent team player and developer you need to be around and help him evolve. This means less of micro management, and more leadership. You need to educate the team member about the domain and give feedback.

Try

• Get the team members to understand why you’re doing something. Don’t just give statements: ask questions back. If a team member asks if A or B is to be implemented, ask him what he thinks. You might learn things that make you make a better decision. You also learn about how he perceives the problem.
• Ask the difficult questions too! Don’t be afraid to ask how things are tested, what the code coverage is and how things are documented? Will this work with 200 users? If you don’t ask these questions and gives thumbs up just based on visual things on a screen, you’re saying that those things don’t matter.
• Invite team members to meet with real users. If a user comes and visit the plant, let the developers meet this person. Set off just an hour to let the customer share his views and for the developers to ask questions. This is often really appreciated.
• Let the Scrum team decide on the sprint length. Just state how often you expect a public release and let them decide if the time between public releases is divided into separate sprints

Avoid

• Rewarding individual achievements over group achievements. It’s very easy to give gratifications to an individual without considering the whole picture.
• Ignoring when a team member does not meet the team criteria. Yes, this is a team question, but you can have requirements on the team member achievements as well. If someone’s lack of competence, interest or devotion cost you in lost velocity, bring it up with the Scrum master.

What if I’m really the only suitable product owner, but I don’t have the time to around all the time?

But I don’t have the time to be with the developers! I can perhaps squeeze in an hour every month. But I know everything, so I better keep that product owner role and assign a proxy?

A term often used in Scrum implementation is product owner proxy. Most of the times I’ve seen this is when the product owner is inactive and the Scrum master takes on his role as well and calls himself product owner proxy.

This is worthless. A role is a personal responsibility and by saying someone is a proxy: who is responsible? In most cases this will result in no one feeling really responsible.

Think of a Broadway play. When one of the actors is sick a replacement is called in. Someone else plays the part. Someone else is responsible for playing that role. That’s not a proxy, that’s a replacement.

If a product owner is not part of the development, the product owner needs to be replaced. A product owner needs to be around and needs to communicate with the team members and stakeholders. A good product owner should of course have routines for involving managers and others so they are "in" on the priorities. Someone always makes the decisions. And chances are that whoever is present makes a decision, even if he’s not aware of it.

Try

• Be available as much as you can. Make the product owner tasks priority or skip the tasks.

Avoid

• Thinking that YOU are the only one. If you think that you can give the best input, is there someone else to whom you can channel this information but can make the daily decisions.
• Having one point of failure in the product owner role. If you get sick, someone needs to be able to work this part. And product owners should also go on holidays.

I’m working in the enterprise, does Scrum really work here?

When I read about Scrum there are always these small teams and products. But we have 30 developers and a big product so then I should stay product owner and assign a number of proxies, or?

In large software developments for large organizations, a single product owner may not be realistic. Because a smooth flow in the Scrum process puts demands on the product owner to the readily available for detailed questions on the prioritized issues, a single person may not be able to be all this for a large system at once.

In this case it’s common to run multiple Scrum teams each concentrating on certain parts of the system, where a Chief Product Owner for some large organizations fills the role of being the single source of high-level prioritization and strategic decision making. Your own organization’s size, decision-making culture and readiness for Scrum should guide you in choosing the right blend for you.

It is important to clarify where one product owner’s responsibility starts and ends in these situations. One example is that the chief product owner is not responsible during implementation phases. It can also be a good idea to have a separate title for the chief product owner.

Try

• Discuss different solution for the scaling of product ownership and just not jump to one solution.

Example of a scaling of the product owner role in a company with an Office product suite including three application where each application has its own product owner, under each there are different product owners for the different features. Observe that this can lead to very different solutions for tables in the different applications.

Example of a scaling of the product owner role in a company with an Office product suite including three programs where each feature has its own product owner and the lowest level is responsible for the implementation in a specific application. This can lead to no one taking responsibility for one application

Am I part of the Scrum team?

I’m the product owner, but does this make me part of the team or am I an outsider. For example, should I talk during Daily Stand-ups?

Why view the product owner as part of the team

Answering questions concerning the stories and requirements are part of the sprint and those tasks should be a part of the work.

If the product owner does not see himself as part of the team, he will not participate in team activities as daily Scrum, etc, and will therefore not be an active part of the daily life. Which result in developers making decisions since the right person is not available to answer the questions.

Why not view the product owner as part of the team

To be able to make priorities, the product owner must be out with customers and users. He therefore does not have time to be available on site and in the daily activities

If the product owner is there constantly, he will micro manage the developers

I've not covered all the arguments in these views, but I think that this catches a bit of the problem: to be able to make the right decisions, the product owner must spend his time outside the team room but to make the decisions come true he must be on site so that the developers don't make daily decisions which contradicts the objectives.

So, how do I think you should solve this? For myself, I solve the problem with sore arms. What? Well, we have three floors and on each floor we have these heavy doors. So, I try to move between the floors as much as I possibly can during the day. I come to the developer's room every day, to chat, to look on progress and if it's possible: I try to help out with whatever I can. It can be arranging a meeting with a technical guru from a supplier; it can be testing, fixing with the Scrum dashboard or just hang out with the guys. I want the Scrum team to view me as part of the crew. A part of the Scrum team.

And it's the same with our users and customers: I try to take part of their everyday activities. Just listen in on their discussions, frustration and happiness. To help out in their daily work when it's possible. Help out with small tasks, find out what is possible to accomplish, formulate a change request or something like that. To make the business people understand that I'm part of their team as well.

And what a joy it is to transfer experiences between these groups! How rewarding it is for a developer to learn that Robert can work more effective now with the new release. And how rewarding it is for a user to hear that Lisa could fix that problem so easily thanks to that really good formulated change request.

So, my answer to the question is yes and no. You should as a product owner have the mindset that you're always part of the team. But you work on all the teams.

So, what do I cut? I try to work my own product backlog and try to do what brings the most business value to the product: in this case my work. Which means that what is most often cut is those long off site meetings which are probably very nice but which in reality brings very little value to my actual work. Which is to make sure that we do the right stuff in our projects. This can also mean that I don't participate in whole meetings. People don't have a problem if I from the beginning say that I actually don't have the time but I can be there for 30 minutes or an hour. OK, I probably miss out a lot of nice trips and lunches but what is that really worth. Really?

Try

• Take on items on the product backlog.

Avoid

• Take on items on the backlog and don’t fix them.

What happened to the project manager?

But I’m the project manager, what happens to me?

What are the objectives of a project manager and which ones of these tasks bring real value to the people, the process and the product? If you read this article and other texts about Scrum, you can see that a lot of the tasks are divided between the Scrum master and the product owner. Some of the tasks are removed all together and some are handed over to the team.

A project manager can be an excellent product owner or the best of Scrum masters. But a project manager can also be a terrible product owner or a lousy Scrum master. In other words, don’t move the project manager over to one of these roles without considering if this is the best solution. Look at the person’s traits and the traits of the roles. If you have a match, go ahead. If they don’t, choose another solution.

An indication if someone is not suitable at all is if they want to combine Scrum master and product owner or if they feel like their task is to "have control". Scrum is trust based, not control based.

Sometimes you need more of the traditional project manager skills. This is most common in an enterprise environment where there are a lot of Scrum teams which are interdependent. A project manager can be the Scrum master of the scrums of Scrum. But this is a tricky position and should be held by a seasoned Scrum master. The Scrum master of the scrums of scrums should not be the one lacking an understanding of Scrum principles but the one who embraces these and can combine this with an enterprise perspective.

Try

• To delete the project manager’s role from the organizational chart
• Use Scrum of scrums in an enterprise environment. This calls for more traits than the ordinary Scrum master.

Avoid

• Placing the project manager by default as Scrum master or product owner
• Placing the project manager who does not embrace the Scrum principles as Scrum master for Scrum of scrums.

Conclusions

Be a good guy. Have fun, empower others and help in making your team the most successful. And go home when the normal office day is over.

Suggested reading

General books - it’s really worth reading them…

The five disfunctions of a team, by Patrick Lencioni
To be able to have a successful project, you need a successful team. This is an example of a book which covers the making of a successful team. There are other books which covers about the same theories, but many agile writers refers to this one.

Scrum from the trenches, by Henrik Kniberg
A very concrete book, which you can download for free from Info-Q or purchase for a small amount. Easy reading and a good view from a developer’s point of view.

Agile Software development with Scrum, by Ken Schwaber
A classic on Scrum as a methodology. Can be a bit abstract and is best read one chapter at the time, when you want to read more on a subject.

Agile and iterative development, by Craig Larman
If you want to know how Scrum works in relations to other agile methodologies, this is a book for you. The first book on agile software development I ever read, and I’ve read it again.

Agile Estimating and planning, by Mike Cohn
My bible as a product owner. Read the whole book and be sure to re-read the chapters that you are most interested in.

User stories applied, by Mike Cohn
If you want to learn how to use the user story format to make a successful project, this is a good book to keep in your book shelf.

Confessions of a serial product owner, by Anna Forss
My collected thoughts on working as a product owner. Can be downloaded for free from DevAgile.com : http://www.devagile.com/modules/news/article.php?storyid=346

Scrum Product Ownership – balancing value from the inside out, by Bob Galen
Where I cover many subjects very briefly, Galen goes into detail. This is a great book for keeping references and understanding the core of Scrum product ownership.

Blogs

My blog: https://annaforss.wordpress.com/

If you are short on time, subscribe to one or two aggregates, for example

http://www.scrumplanet.com/aggregator

---

Related Scrum Articles

Agile, Multidisciplinary Teamwork

Adaptative Project Management Using Scrum

Opening Communication within a Scrum Team

---

More Scrum Resources

Scrum Expert

Agile Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Summer 2009 issue of Methods & Tools