Tag Archives: ScrumMaster

RertoFeaturedImage

The Retrospective in a Nutshell

The sprint retrospective is an opportunity to pause for a short while and reflect on what happened in the sprint. This allows the attendees to improve their collaboration and their work practices to get even better at creating a great product.

The meeting takes place right at the end of the sprint after the sprint review meeting. Its outcome should be actionable improvement measures. These can range from making a firm commitment to start and end future meetings on time to bigger process changes. The retrospective is not a finger-pointing exercise. As Mahatma Gandhi famously said: “Be the change you want to see in the world.”


Take Part

As the product owner, you are a member of the Scrum team, which also includes the development team and the ScrumMaster. While you are in charge of the product, you rely on the collaboration of the other Scrum team members to create a successful software product. If you don’t attend the retrospective as the product owner, you waste the opportunity to strengthen the relationship and to improve the collaboration with them.

TheScrumTeam

But there is more to: Taking part in the sprint retrospective allows you to understand why the team requires some time in the next sprint to carry out improvements such as refactoring the build script, or investigating a new test tool; and maybe more importantly, it helps you improve your own work.

Say that some of the user stories the team had worked on did not get finished in the sprint. At first sight this looks like the development team’s fault. But analysing the issue may well reveal that the size of the stories and the quality of the acceptance criteria contributed to the problem. As you are responsible for ensuring that the product backlog is ready, this finding affects your work: It shows you that you have to decompose the user stories further and it suggests that the development team’s involvement in getting the stories ready should be improved – otherwise you would have spotted the issue before the stories went into the sprint.

If you had not been in the retrospective would you then whole-heartedly support the resulting improvement measures and change the way you work?


Be an Active Participant

Don’t attend the retrospective as a guest who will speak when asked but otherwise remains silent. Be an active participant, use the sprint retrospective to get feedback on your work, and raise any issues that you want to see improved. Be constructive and collaborative but don’t shy away from tough problems.

POAsActiveRetroAttendee

Here are some questions that you may want to explore in the retrospective:

  • Do you spend enough time with the development team? Are you available to answer questions or provide feedback quickly enough? Do you provide the right level of feedback and guidance in the right way?
  • Is the communication between the team and you open, honest, and trustful?
  • Does the team know how the users employ the product?
  • Are the team members happy with their involvement in analysing user feedback and data, changing the product backlog, and getting stories ready for the sprint? Do you get enough support from the team to “groom” the backlog?
  • Are the team members aware of the big picture – the overall vision, the product strategy, and the product roadmap? Do you get enough of the team members’ time to help you with product planning and product roadmapping?

Improve the Wider Collaboration

As important as it is, continuously improving your collaboration with the development team and the ScrumMaster is usually not enough. You also need strong relationships with all the other people required to make the product a success. These include individuals from marketing, sales, customer service, finance, and legal, as the following picture shows.

POWiderCollaboration

A great way to review and improve the collaboration with your partners from marketing, sales and so forth is to invite them to the retrospective on a regular basis. Depending on how closely you collaborate, this may range from once per month to once per major release. A joint retrospective will help you develop closer and more trustful relationships, help smooth the launch of new product versions, and improve selling and servicing the product.

Here are some questions that you may want to explore in an extended retrospective:

  • Are the partners from marketing, sales etc. involved enough in the product planning and roadmapping activities?
  • Do they regularly participate in the sprint review meetings? Are the review meetings beneficial for them? Do they understand the project progress?
  • Do they receive the information necessary to carry out their work in a timely manner, for instance, to prepare the marketing campaign and to compile the sales collateral?
  • Do you get enough data and support from the partners, for instance, regular updates on the sales figures and the market feedback you require?

You can, of course, also discuss these questions one-on-one. But getting any issues on the table and discussing improvement opportunities creates a sense of we-are-all-in-this-together; it reaffirms the need for collaboration and teamwork to provide a great product; and it can break down departmental boundaries.


Learn More

You can learn more about the sprint retrospective meeting and the product owner by attending my Certified Scrum Product Owner training course. Please contact me if you want me to teach the course onsite or if you would like me to run a product owner workshop at your office.

ProductOwnerScrumMasterFeaturedImage

Product Owner vs. ScrumMaster

The product owner and ScrumMaster are two different roles that complement each other. If one is not played properly, the other suffers. As the product owner, you are responsible for the product success — for creating a product that does a great job for the users and customers and that meets its business goals. You therefore interact with users and customers as well as the internal stakeholders, the development team and ScrumMaster, as the following diagram shows.

ProductOwnerRelationships

The grey circle in the picture above describes the Scrum Team consisting of the product owner, the ScrumMaster and the cross-functional development team.

The ScrumMaster is responsible for the process success — for helping the product owner and the team use the right process to create a successful product, and for facilitating organisational change and establishing an agile way of working. Consequently, the ScrumMaster collaborates with the product owner and the development team as well as senior management, human resources (HR), and the business groups affected by Scrum, as following pictures illustrates:

ScrumMasterRelationships

Succeeding as a product owner requires the right skill set, time, effort, and focus. So does playing the ScrumMaster role. Combining both roles – even partially – is not only very challenging but means that some duties are neglected. If you are the product owner, then stay clear of the ScrumMaster duties!


What the Product Owner should Expect from the ScrumMaster

As a product owner, you should benefit from the ScrumMaster’s work in several ways. The ScrumMaster should coach the team so that the team members can build a great product, facilitate organisational change so that the organisation leverages Scrum, and help you do a great job:

ExpectationsOnTheScrumMaster

The following table details the support you should expect from the ScrumMaster:

Service Details
Team coaching
  • Help the team collaborate effectively and manage their work successfully so that they can make realistic commitments and create product increments reliably.
  • Encourage the team to work with the product owner on the product backlog.
  • Ensure that the team has a productive work environment.
Organisational change
  • Work with senior management, HR and other business groups to implement the necessary organisational changes required by Scrum.
  • Educate the stakeholders about what’s new and different in Scrum, explain their role in the agile process, and generate support and buy-in.
  • Resolve role conflicts such as product owner vs. product manager and product owner vs. project manager.
Product owner coaching
  • Help the product owner choose the right agile product management techniques and tools.
  • Support the product owner in making product decisions and tackle product owner empowerment issues.
  • Help establish agile product management practices in the enterprise.

The ScrumMaster supports you as the product owner so that you can focus on your job – making sure that the right product with the right user experience (UX) and the right features is created. If your ScrumMaster does not or cannot provide this support, then talk to the individual, and find out what’s wrong. Don’t jump in and take over the ScrumMaster’s job. If you don’t have a ScrumMaster, show the list above to your senior management sponsor or to your boss to explain why you need a qualified ScrumMaster at your side.


What the ScrumMaster should Expect from the Product Owner

It takes two to Tango, and it’s only fair that your ScrumMaster has expectations about your work as the product owner. The following picture illustrates some of them:

ExpectationsOnTheProductOwner

The table below describes the ScrumMaster’s expectations in more detail:

 Service  Details
Vision and Strategy
  • Provide a vision to the team that describes where the product is heading.
  • Communicate the market, the value proposition and the business goals of the product.
  • Formulate a product or release goal for the near to mid term.
Product Details
  • Proactively work on the product backlog. Update it with new insights and and ensure that there are enough ready items.
  • Provide direction and make prioritisation calls.
  • Invite the right people and choose the right techniques to collect feedback and data, for instance, invite selected users the review meeting and carry out a usability test.
Collaboration
  • Be available for questions and spend time with the team.
  • Buy into the process and attend the sprint meetings.
  • Manage the stakeholders and make tough decisions; say no to some ideas and requests.

You can find more a more comprehensive description of the product owner duties in my post “The Product Owner Responsibilities“.


Learn More

To learn more about the collaboration between the product owner and the ScrumMaster attend my Certified Scrum Product Owner training course. Please get in touch if you have in questions or if would like me to teach the course on-site.

If you feel that your ScrumMaster would benefit from improving her or his work, then I recommend Geoff Watt’s book “ScrumMastery: From Good to Great Servant Leadership”.

The following list is a tongue-in-cheek collection of common mistakes in applying Scrum. They all influence product success negatively. Combined they are a recipe for certain failure.

  1. Apply the product owner role pragmatically: Spilt the role across several people or work with a product owner committee.
  2. Shoot for the maximum marketable product – a product that pleases everyone and has a myriad of features.
  3. Have a can-do attitude, say yes to every requirement, and put it into the product backlog. You don’t want to disappoint stakeholders and endanger the product success.
  4. Capture and detail all the requirements in the product backlog before the first sprint. This reduces uncertainty and risk, and it enables accurate planning and efficient execution.
  5. Don’t bother with prioritisation. All your requirements are certainly must-have’s.
  6. Don’t ask your customers for feedback on early product increments. You know what’s best for them!
  7. Leverage a big-bang release to surprise your competitors, impress your customers, and achieve complete market domination over night.
  8. When push comes to shove, add more features and cut quality. Customers love complex products. Don’t worry about technical debt. View it as an opportunity to create a new product in the near future.
  9. Tell the ScrumMaster to act as a proper project manager. Work the team hard. Sustainable pace is for wimps.

To avoid the mistakes above and to learn how to create great products with Scrum, refer to my book Agile Product Management with Scrum, or book yourself on one of my product owner trainings.

It’s not uncommon for me to visit a new client and to discover that the scrum teams change frequently, sometimes after every single sprint. Changing the team composition too frequently is undesirable for the individuals and the organization. To flourish, teams need stability. With markets, requirements and technologies frequently changing in an agile world, a stable scrum team provides security and continuity.

To create stable scrum teams, follow these recommendations:

First, carefully consider who should be on the Scrum team. Find the right individuals to play the product owner, ScrumMaster and team role in order to develop a great product. Having the right individuals on board is most likely the biggest success factor for any development effort.

Second, minimize any changes to the Scrum team within and across releases. It takes some time for a group of individuals to become a true team – a tightly knit unit with members that trust and support each other and that work together well. Changing the team composition makes this teambuilding process start all over again and, as a result, productivity and self-organization suffer. Avoid loosing team members while a release is being developed. A good time for people to leave and new members to join is after the release of a new product version. But ensure that the majority of the team members continue to work on the product to avoid loss of information, defects and delays.

Last but not least, establish a long-term partnership between a Scrum team and its product; every product should be developed by one or more dedicated teams. This not only facilitates ownership and learning, but it simplifies the allocation of people and resources.

The product owner should always be a permanent member of the Scrum team. This allows the individual to manage the entire product lifecycle, from gestation to its discontinuation. It also encourages balancing short-term wins with long-term success.

Find out more about employing stable teams by reading my book Agile Product Management with Scrum or by attending my product owner course.