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.
Sprint Meetings
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.
On to Standups
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:
- No one says anything. That likely means that no other app needs that feature. Maybe that feature is better implemented in the app team’s code base.
- Other App teams say they need (or will soon need) that same feature. That information helps the framework team prioritize requests.
- Another App team says "we’ve already built that feature." Now, the work changes from a new feature to refactoring code (and associated unit tests) to move it from the application’s codebase to the common framework. That avoid code duplication, and means the framework team can release the new feature more quickly.
It’s working quite well so far.
What have you tried? How has it worked?