It’s always a matter of Imagicle People.
Once we had identified our two products, it was time to connect the Imagicle people with them!
The Product Owner.
Each product identifies a Product Backlog, which is prioritized by a Product Owner (and only one).
The two Product Owners were then identified for the two products (and this time we promised not to overload them with work, as we recognized in the Agicle Retrospective ).
The LeSS definition refers to multiple teams working together on one product. In fact, LeSS has the potential to overcome the limit “a product – a team” required by Scrum.
Now we could easily move from one distributed team to two co-located teams (and co-located teams, regardless of their size, are always to be preferred). And so we did for Unified Communications, which now has two teams working on it. Cloud Service, for now, can be managed by a single team (so it’s actually developed with the Scrum framework).
The Scrum Masters.
To complete the reorganization of R&D people, all we needed were the Scrum Masters.
According to the Scrum Guide, the Scrum Master “is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”
We have identified two of them so that they can always be present in the two different locations where the teams work.
Well well, now. A few months after the adoption, let’s see what are the observable results related to the critical points observed in the Agicle Retrospective.
At the time we used to work with a single cross-site team, the Daily Scrum was dispersive and time-consuming. The reports had a level of detail that made sense only to those who were actively involved in the development of the story.
With LeSS, the Daily Scrum is broken down by teams, so everyone talks about what they’ve done and what they’ll do to people interested in that level of detail. Furthermore, in order to still have an opportunity to stay aligned, each team sends a rotating representative to listen to the Daily Scrum of the other side and to brief their team on the state of the work. This set-up has made Daily Scrum more effective and efficient.
Product Backlog Refinement.
One of the most significant problems we highlighted in the Agicle Retrospective was the management of the Product Backlog Refinement. We didn’t do it regularly, and when we did it, we went into too much specialty in analyzing the issues, going into details that could easily have changed by the time the item would enter the Sprint Backlog.
Today we have a one-hour timeboxed refinement sessions a week, without exception. During these sessions, we only verify that everything is clear for each item. If so, we assign the item a story point estimate based on its complexity. Conversely, if there are aspects to be clarified, we establish who and how will deal with it (e.g., addressing a stakeholder). At the next refinement, the person in charge of defining the unclear aspects will inform the teams about it. Then, if satisfactory, the item will be estimated.
This new refinement mode has brought substantial improvements:
- We can refine more items in less time;
- By taking care of defining the items, the teams relieved the Product Owner from activities that were not his responsibility (the “MAD” section of the Retrospective), allowing him to have enough items on the Backlog to carry out his prioritization activity efficiently.
- Although the estimate may not be as accurate as it used to be, it’s definitely sufficient for the team to define with the PO the goal of the following Sprint and the items that have to be completed.
- By taking care of clarifying the items with the stakeholders, the teams are more empowered (and the greater responsibility of the teams brings, in turn, other positive effects).
In the previous post on the Agicle Retrospective, Riccardo told you there was no real planning at the start of the sprint, mainly due to the scarcity of refined items that could be planned.
We’ve just seen how this is no longer a problem. So, by now even Sprint Planning should be sorted, right?
Exactly! Now, at the beginning of each sprint, the Sprint Planning part 1 takes place (LeSS divides the Sprint Planning into two parts). The Product Owner communicates to the representatives of the teams (still in rotation) what’s the goal of the sprint that’s about to start. At that point, the teams, through their representatives, split the items and build the respective Sprint Backlog.
So yes: now the Product Owner and all stakeholders know immediately how the product will be increased during the next sprint.
After this part (timeboxed 30 minutes), the teams meet separately and move on to the Sprint Planning part 2, dealing with the design of the solution and the technical details. This activity, which usually took time during the refinement phase, now allows us to involve in the technical details only the people required for the purpose. Also, we can postpone the technical decisions as much as possible, thus having the maximum possible knowledge available. All bearing in mind one of the fundamental principles of the Agile Manifesto: “The best architectures, requirements, and designs emerge from self-organizing teams.”
Another sore subject of the Agicle Retrospective was the management of the Sprint Review. In fact, for each item we used to verify the entire set of Acceptance Criteria with the Product Owner, preventing him from doing…the Product Owner! Besides, the highly technical approach had made the event insignificant for stakeholders.
Now, the acceptance criteria are verified throughout the sprint. This means that, during the Sprint Review, we are now able to present the product increase in a stakeholder-oriented way, allowing them to see and touch the news and give us immediate feedback for subsequent iterations.