Scaling Agile: LeSS Scrum adoption.

Scaling frameworks.

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.

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.

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 teams.

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.

Agicle 2.0.

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.

Daily Scrum.

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:

1. We can refine more items in less time;
2. 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.
3. 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.
4. 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).

Sprint Planning.

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.”

Sprint Review.

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.

Conclusions.

Of course no. By now, we well know that everything is based on the concept of inspecting&adapting. Someone would say it is a path…, or, maybe, we have grasped and put into practice what the Agile Manifesto truly means when it states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.