Scaling Agile – a Real Story

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

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.

Tips
Throughout the article, you will find highlights and tips – in boxes like this one. Here comes the first tip ...Have enough facilitators for big room planning
Based on the level of Agile & team maturity, make sure that you have enough facilitators for your big room planning. One facilitator can typically handle between one and three teams.

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!
Create ownership by giving control
In a large program (and in all other situations for that matter), you want the individual people to take ownership. Otherwise, you will never succeed. With so many people, there is no way that you as a manager can plan and steer the program to reach the goals. And you can only get them to take ownership if you give them control, rather than you taking control.

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.
Set a date – drive people to get ready
Setting a somewhat optimistic date for the first big room planning is a driver for everyone to get ready. If you wait until everyone is ready, you might wait forever.

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.

Understand by asking all the questions first
A good technique for getting people to create a deeper common understanding is to have them brainstorm all the questions they can think of before you start answering any of the questions. It helps cover more ground than the usual question -> answer -> question -> answer. This is very useful technique for backlog refining, including refining ahead.

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.

Understand by starting from scratch
It can often be more efficient to create a common understanding by starting from scratch and trusting the knowledge and memories of people, rather than trying to interpret someone else’s work.

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.Gauge program progress by rough program points
Rather than only gauging program progress by summarizing all the detailed progress reports, which often is very time consuming, you can get a quicker and earlier picture by rough estimates on the high-level epics, and do the math on those.

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.Increase cross-team collaboration by visualizing team-epic involvement
Making it visible that more than one team is involved in the various epics increases the cross-team collaboration during and after the big room planning.

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?

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

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