Scaling Agile – a Real Story

Having several teams working together in an Agile way to speed up delivery of new products and services to their customers is, for many companies, the answer to the rapid changes we see in the marketplace today. Scaling Agile, however, is a bigger and different challenge than "just" implementing Agile at the team level. It's an organizational and behavioral journey ...

This is the first in a series of articles about making scaled Agile work with slicing, master planning and big room planning. It is the true story from one particular program in a financial services company, the EU Mifid regulation of extended responsibility for investment advisors.

The names of the people have been changed.

Before we dig into the story, let’s get the vocabulary in place. The Mifid program decided to follow the steps of what I call Scaled Planning.

Scaled Planning

Scaled Planning, including slicing and master planning, is a pragmatic approach to help you with your scaled planning challenges. Scaled planning uses the organization’s overall strategic objectives (the target in the middle of the illustration) as the starting point, and from there involves four levels of planning:

1. Slicing
2. Master planning
3. Big room planning
4. Sprint planning

While the various scaled frameworks provide a useful framework for the quarterly big room planning, where all teams and stakeholders get together for a couple of days, and while most organizations know how to do sprint planning, many struggle with getting 100% ready for the big room planning. This is where Scaled Planning with 1. slicing and 2. master planning comes in.

And now to the Mifid Program and the first big room planning in June

After I joined the program in May, one of the first things we did was to set a date for the first big room planning for June 16-17. We invited everyone on all the involved teams plus other key stakeholders from the Business and a couple of the people responsible for the organizational implementation. There was a lot of discussion about the timing. The big question was, "Will we be ready?" ... Pia, the Chief program points, Sally the Chief scrum master and I kept to the date, thinking that it would drive everyone to get ready. And it worked. Almost as great as we thought it would. More on that later.

Before the big day, Pia had managed to get the various parts of the Business to describe and deliver the epics that they needed, seen from their individual points of view.

And then, finally, June 16th came and everyone met in a big room. After Pia reminded us about the business benefits of Mifid (compliance to the EU regulation & better investment advice and service for the bank’s customers), in my role as the main facilitator, I presented the program for the two days. See illustration: Planning agenda - for each team.

Each team chose the epics they felt belonged to them (see illustration Epics & teams), and started to break them down into user stories.

And then the problems started ...

The Online Banking Team did not see that they had any epics of their own. So why even stay at the big room planning?

Another team had 12 people sitting around a table. A couple of them were talking, and all the others were just sitting quietly looking frustrated.

Other teams – with better dynamics – simply did not understand the epics, and therefore had a really difficult time breaking them down into business features.

What a mess!

I asked the Online Banking Team to step outside with me so we could talk. I had a burning question about how they were organized. Their team seemed like a silo to me because they were "just" a channel for everyone else's products – including the investment services. But I didn't talk to them about that, since it was not this team’s idea to organize in this way. Instead, we agreed that they would split up and participate in the big room planning with the other teams. Which they did, sort of. It took a lot of nudging to keep them close to the other teams.

Pia, Sally and I agreed beforehand that we would split the teams between us, and facilitate two teams each.

The 12-person team was another nut to crack. It was simply too large a group to do any meaningful planning together. I approached them and told them. They all just looked at me, and right before I was about to just tell them to split up, Pia came up to me and whispered, "Shhh, Ole. Try to let them be, see what happens". And then, after a few more minutes they all got up, and ended up in two groups, having two separate discussions. And soon, they were working on two separate team boards. They had self-organized into two teams. Awesome!

Now, we only had the we-do-not-understand-the-epics problem left to solve. But no matter what we did during this big room planning, it did not solve the problem.

It became painfully clear to us that we introduced the problem ourselves by having the individual parts of the business describe and deliver the epics to the program. Had we pushed too hard by sticking to the June date? Would the teams have been more involved in describing, and thereby understanding, the epics if we had given them more time? Actually, we did not think so. We took this as a learning opportunity – promising ourselves to support the teams to better understand the epics before the next big room planning three months later.

Slicing – Refining – Understanding

After the teams somehow managed to get going on developing some of the business features (there was a lot of interaction with the business – finally!!), they wanted to get ready for the next big room planning. There was a pull from the business side, which I thought was wonderful. We had created a sense of ownership. It was no longer the program management’s plan – it was their plan.

One of the teams asked me to help them by giving them the answer to this question: what does a perfect epic look like?

I looked around at epics from my past programs. And other epics from other programs. And I thought about it, and I kept looking some more, becoming frustrated that I couldn’t find a single epic that I thought was perfect.

Then I started thinking about what had made the difference between successful programs and unsuccessful programs, and realized that it had nothing to do with the format of the epics – or any other templates or requirement specifications for that matter.

I met with the team and shared with them what matters when it comes to slicing and refining requirements:

1. Understanding together
2. How you slice your epics
3. Format of description

Prioritized, and in that order, so the epic format is the least important of the three.

We did two things to start understanding together. First, we grouped the requirements they had brought with them. A good mix of epics, features and stories. Someone asked: "Is this Story Mapping", and I said, "Yes", and explained how I see Story Mapping as simple as: laying your requirements out on a table, and moving them around to create a structure that makes sense, preferably with potential releases as a part of the structure.

This led to a heated discussion about how to organize the requirements. Most of the requirements were about three new investment banking products from simple investment advice to full investment portfolio support. Most of the people argued that the slices (the potential releases) should be the products, so we would develop one product 100%, release it to the market, and then move on to the next product. A couple of other people argued that we should first get all the legal issues figured out for all three products while we had the lawyer involved anyway, then the marketing plan for all three products, and then everything else before launching all three products at the same time.

I recommended the product-by-product approach (see illustration Story mapping – which way?) as a better way of slicing, in order to get to actual smaller and potential releases earlier, to increase early feedback and learning. That was what the team agreed on.

Now it was time to go deeper in each of the requirements, and we did that by taking one requirement at a time, and refining in this way: 1. Brainstorming all questions that we could come up with and write them on red sticky notes and post them on the paper with this particular requirement. We kept going without answering any of the questions until we could not think of more questions. 2. Then we started trying to answer the questions one by one and wrote the answers on green sticky notes. Some questions we could not answer, so that became the program points’ responsibility to find the people who could answer those questions.

Slicing and understanding – start from scratch

Meanwhile, a different team on the program worked to figure out some of the epics from the big room planning that they still did not understand. The scrum master had printed them all out and organized a workshop and the program points was ready to try to explain.

For the first couple of hours, they sat around a table having a discussion around these epics. But they didn't really get anywhere. There were no conclusions. And it felt confusing. We agreed to move to the other end of the room and lay out the eight epics, and started to write tasks on index cards, and place them by the epics. No matter how hard the scrum master tried to organize the cards, and no matter how hard the program points tried to explain what he thought was in each epic, the confusion didn't go away.

Then someone said, "Why don't we push all the old epics aside, and write our own new epics. That way we don't need to guess what someone meant when they wrote those old epics."

Then something happened!

After just a couple of more hours, the team was ready with their new epics, ready to run them by their stakeholders to make sure that they were still on the right track.

Getting ready for the next big room planning – with master planning

While we were getting ready for the next big room planning in October, we talked about all the problems we had the first time, and realized that two more things had not been optimal:

• We did not have a clear enough picture of the long-term plan for Mifid
• The different parts of the business did not agree on what was most important and urgent

We did have a master plan from last time, but it was only really robust for the next three months and shaky for the following many months. Therefore, people got confused about what to take into this big room planning and what to postpone for the future.

Also, some business areas were very keen on living up to the Mifid regulations in every detail, where others were more focused on the customer experience.

In other words, no clear direction. Leaving room for people to spend a lot of time discussing the direction, and to pull in different directions, during and after the big room planning.

We decided to get additional stakeholders involved in a master planning session in late September, before the next big room planning in October. We invited the program points from each team, the steering committee, three business heads and Pia, Sally and myself – a total of 12 people.

We started by getting a feel for how far we were after three months. Out of a total of 15 epics, two were finished and seven were at around 50% done. Not where we wanted to be.

Then, we estimated the epics using planning poker with t-shirt sizes. It was great to see the level of engagement from everyone.

We prioritized and I insisted that all epics were in one line to get the business heads to agree on what was most important for the entire company. One of them said to me, "I know what is most important for my area, but how can I know what is most important for the other business heads?" He said this while he was standing right next to one of the other business heads, and I just smiled, and looked around the room. "Ahhh", he said. "I can just talk to them." Bingo!!

After they had a really involved discussion about how much they thought we could get done in the upcoming three months, they reached a conclusion: the next 26 epics.

Meanwhile, I had done the math (see illustration Program points). I had calculated that the epics we had planned for the first three months were equivalent to 228 points using a conversation scale from t-shirt sizes to what I call program points. We only got 125 done (97 of the planned, plus 28 extra unplanned work).

Using the same method, I figured that they were about to aim for 606 program points in the upcoming months!

We adjusted the ambition significantly, and we were ready for the next big room planning.

Next big room planning – October

October comes, and everyone got together again. We saw more people than last time. The Online Banking Team brought some of their colleagues. And a couple of the business heads showed up too. Apparently, people heard about it, and wanted to be a part of it.

We started by looking at what we had achieved the last three months, using the same overview as at the master planning. And then, we presented the result of the master planning, which was still somewhat ambitious, but not at the 606 Program Point level anymore.

Then the teams gathered around the epic overview board, and this time we asked them to think about all the epics in which they played a role, even if it was a small role. We then got everyone to put a small colored sticky note representing their team on those epics (see illustration Epics & teams II).

After about one hour, we had an overview of which teams were primary drivers on which epics – and which other teams were also involved in each epic.

It surprised us how powerful this was. There were a lot of people standing by this board, coming and going throughout the two days, and it was usually people from different teams having a discussion about what they needed from each other, how they could help each other.

The next thing that happened, with surprisingly little guidance, was that the teams started to break down and estimate. I noticed that both Sally and Pia hardly did anything to make it happen. And neither did I.

I was very happy, thinking that all our not-telling-people-what-to-do, but rather letting them drive their own understanding and making their own decisions, and also involving and engaging them in the first big room planning, was now clearly paying off. The new ways of working had been internalized in the teams and people. We were about to achieve lasting change!

While the teams worked on their planning and collaborating with other teams, Sally had time to improve the program board, getting it ready for the teams to post their features. She had brought some nice tape, and organized the board, including measuring out the space for a certain number and size of sticky notes per team per sprint. Meanwhile, she was thinking that the first program board had a lot of information on it, making it harder to get the overview. So, she decided to ask the teams to give their features a short name, and only write that name on the sticky notes that they put on the program board.

The result was a much better structured program board with fewer details, giving a far better overview, and therefore, a far better tool for the weekly Scrum-of-Scrums, where all scrum masters, program points and other stakeholders gather to coordinate and gauge actual progress and comparing it to the plan.

I was curious about the perception of the time spent on the big room planning, so I asked a few of the people who had been skeptical the first time. Here’s what a couple of them said:

How has it been to participate in the big room planning?

It has been exciting. Really good that many stakeholders participated, to get the conversations going between us. Discussing the tasks and the estimates across the program. This is big. Complicated. Like spaghetti. I think everyone has learned a lot.

Really good. It is giving lots of insights – understanding what others are doing. The program board is giving a super overview.

Two days is a lot of time. Has is been worth the investment?

"Yes, definitely. And that has surprised me. In the beginning, I thought that two days was overkill. But everyone learned a lot. We now know that we need to talk to each other. To work together. It’s been a good investment."

"It’s worth every penny. We can just go and talk to others, when something comes up. Normally, we don’t do that. And look at the activity level in the room. Very high."

What could we have done differently?

Of course, not everything was perfect. And we kept learning. One of the main things we should have done differently was this:

We experienced a need for extra attention on one of the epics. The deadline for this particular epic was harder than the others, and it was more complicated with more teams and stakeholders involved. We tried to fix it by nominating an epic owner, and it helped, but not enough. We did not meet the deadline, and therefore had to pay for one more year of a particular software license. Looking back, we should have insisted on moving the two most involved teams closer together.

Summary

This was my story, which I hope gave you some real-life-perspective on the key takeaways that I mentioned in the beginning of the article:

• Getting ready for a two-day big room planning takes time. Prioritize it!
• Early on, set a date for the first big room planning to drive everyone to get ready.
• Then, involve teams substantially in understanding the epics by slicing and refining.
• Now, get key stakeholders to agree on direction by building a master plan together.
• Finally, when you run your big room planning, adjust the number of facilitators according to the maturity of the teams, and know that your first time will generate a lot of learning for your next time

Next articles

In the next articles in the series, I will dig deeper down into slicing, master planning and big room planning, sharing more experiences and giving more specific tips and tricks. Stay tuned ...

About the Author

Ole Jepsen is an Agile transformation advisor working with organizations looking to lead change. Using his expertise in Agile methodologies, Intent-based Leadership™ and facilitation, Jepsen works with companies and leaders to create development organizations and workspaces where people thrive and deliver value.