Just a short link post today.
Fellow Regional Director and Microsoft ALM MVP Adam Cogan has produced the first of many videos that define roles in a scrum team. The first video defines the role of the Product Owner.
I highly recommend this video, and I recommend that you subscribe to the videos that will follow. It’s short, only a few minutes. It’s super well written, and it’s a great short reference to the tasks that a product owner is responsible for.
It will help both your product owners, and the rest of your scrum teams.
One of our customers is grappling with how to manage a scrum process that involves multiple teams with multiple responsibilities. The larger organization produces a number of business applications, all built on a common library. They have teams for each application, and a framework library team.
I thought our recommendations would be of general interest, so I’m posting them here. This is still a work in progress, so I'd appreciate any thoughts from my readers.
We recommended moving away from a process where every team attended one large sprint meeting. Every team planned their next sprint during these large meetings. Our customer was concerned that there was very little energy in these marathon meetings. The main reason was that for many attendees, over 75% of the content was not interesting: it was about other applications. The level of detail was too deep for members of other teams. By scheduling project-specific sprint meetings, each meeting had fewer people, and those people were engaged in the activity.
To make sure that the voice of the customer was represented, we recommended that one member of each application team attend the framework team's sprint meetings.
To make sure that the framework team knew of any issues relating to each application, we recommended that one member of the framework team attend each application team meeting. (Although not necessarily the same person. That would be a lot of meetings).
We made this recommendation because sprint meetings are in depth, and project focused. We feel it's important to have all attendees engaged for the entire meeting. We wanted to reduce the waste associated with attending meetings where someone is not really contributing.
It did raise the energy in the project meetings. It also brought some concerns. Everyone felt this decreased the communication between application teams. That could lead to code duplication, missed opportunities for reuse, and siloes of knowledge.
Standups are a mechanism to communicate to everyone any progress, and any issues. We recommended having all the application teams and the framework team attend the same daily standup. That’s about 30 people, but it can still be a short meeting, if everyone follows the rules. We're finding two main advantages to this process.
If someone is stuck, a larger group of peers hears about the issue. That increases the chance that someone will say "I can help." Issues get solved quicker.
The framework team is becoming much more efficient. Imagine someone on an application team makes a feature request of the framework team at one of these standups. One of three outcomes are possible:
It's working quite well so far.
What have you tried? How has it worked?
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.