11:30 AM EDT Register
Scaling Agile: LeSS Scrum adoption.
In his article on Imagicle’s Agicle Retrospective, Riccardo told you how, after five years of “Agicle” software development, the R&D department tried to further improve its way of working and adjust it to the new challenges ahead, including the significant growth of the R&D department.
Over the years, our distributed team – which, in itself, presents us with non-trivial challenges – had grown far beyond the number of 9 people recommended by Scrum, a limit beyond which coordination becomes difficult and Empirical Process Control ineffective.
The problem then was: how can we have more than nine people (potentially many more) working together on the same product without wasting time and energy?
Come to think of it, the question was already answered: to take our Agicle system to the next level, we had to do more. With LeSS.
LeSS: Large-Scale Scrum.
The starting point. Defining the products.
Since “LeSS is Scrum”, it’s also based on the product concept.
The first thing we did was to “spill on the table” all our applications in order to group them into products, as LeSS suggests. In particular, we made sure that the product was as broad and customer-centric as possible.
Now, there are reasons why LeSS prefers broader product definitions:
- they allow a greater focus on the problems of end customers, facilitating the prioritization of activities;
- they expedite the resolution of interdependencies among different products.
After this revision, our product definition was broader than the original one; so much so that, of all that we produce (and this blog is among those things), the resulting products were only two!
And this is indeed a very positive thing.
But how can we accomplish this product grouping?
In the simplest possible way: by asking ourselves questions to establish an order of priorities to know what to work on first and what to work on next.
For example: can I determine if it’s more urgent to work on a virtual fax feature than on an operator console bug? Yes? Great. Then these two applications are part of the same product. But can I set a priority order between an update in the operator console and an update of the blog graphics? Nope. Therefore these two operations are part of two different products.
As anticipated, in our case this survey led us to define two categories of products:
- unified communications, which, among several applications, includes the Application Suite and the Attendant Console;
- cloud services, which consists of the Imagicle website, this blog, etc.
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.
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.
You might also be interested in…
Tech Specs BlogImagicle contribution to Open Source: WireMock.GUI.The Open Source world now has an Imagicle touch: discover WireMock.GUI, our internal tool written in TDD and developed by our R&D team that mocks the behavior of a web server.
Release BlogCall Rec boost: from 180 to 500 recordings on the same server.Leveraging all the hardware space with the same performance level, enabling 500 simultaneous recordings.
Tech Specs BlogThree more bites to Imagicle’s Design For People process.Imagicle UX Greta tells about three steps of the Exploration phase of UX software design for people: Brainstorming & sketches, Wireframing, Prototyping. Discover a reliable and programmatic way to understand the needs, aspirations, and emotional touchpoints of customers and users.