Release Planning Day

Earlier this year I wrote about our Release Pre-Planning. This time I wanted to take things a bit further. We had previously been discussing about the Release Planning Event described in the Scaled Agile Framework. Going for a two day meeting with the whole company sounded like something that could be useful, but would maybe require move convincing than I could do in a short period of time. But if I started with just one day...

So I made a preliminary plan for a one day's Release Planning Event. Rough schedule with the important events and list of requirements from some of the key actors like the Product Managers and Business Owners. Then I communicated this to our technology head who received a nice buy-in from the whole management. Of course something like this could not take place without a proper management support. After this I invited everyone in the company to the event.

Fig 1. Schedule of the Release Planning Day

As a groundwork, the Product Managers were asked to put their Roadmaps in order and the Business Owners to prepare for a short presentation about the current state of our business. All the necessary meeting rooms were booked. The main meeting hall has high level audio-gear with microphones and loud speakers. We have development teams on multiple sites. (Actually I booked almost all of the meeting rooms in the office to make sure people would concentrate on this event. ;) )

At the start of the day I gave a really short overview on what would be coming. Then we quickly moved into the business context. Our two Business Owners told us briefly about the most recent trends in the markets and what could expected in the future.

Fig 2. Different levels of planning.

Next, our Product Managers presented their updated Roadmaps. Figure 2 is very close to the view I have on breakdown of different levels of planning. Outside the outermost circle I would still like to have company strategy, but I'm lazy with the pictures. As the Roadmaps are still rather new concept for us, they again raised a lot of discussion, but in a constructive spirit.

Surprisingly after first hour and a half, we were still on schedule! After going through the Roadmaps I explained the plan for the rest of the day. The purpose for the whole day was to craft Release Plans for our product teams. In addition to those, I wanted people to identify the possible dependencies and potential risks. Making those transparent would help us address them later.

Then we had the first Team Breakout. People moved into their team rooms together with the stakeholders. Target was to get some kind of draft plan that could be refined later. This time period included also the lunch (most people are more productive if they get a decent meal during the day.)

One o'clock in the afternoon we met again with the whole company and started to go through the draft plans. This was also a time to face the reality and notice that some Product Owners and one Product manager were not present hence making it impossible for some teams to craft their plans. This was remedied by agreeing that those plans would see the daylight next week. No panic there.

But going through the draft plans helped to identify a couple of topics: as quite often, some of the plans were really optimistic. And there were dependencies between the teams and some general confusion about what to do. We didn't settle these problems right there and then. They were just identified publicly and settled later by the teams themselves.

Originally I planned to have a physical board for writing down Risks and Dependencies and a webcam for having it visible in the remote offices. Then I realized that it would make more sense to have the board in digital format, so in the end the things were written to a Confluence page.

Second Team Breakout helped to build more realism into the plans. At the end of the day we met again at the common square. This time the plans looked a lot more realistic and people gave a (really symbolic) vote of confidence on the plans. Some of the plans could have been refined a little more, but the results were satisfactory. We had plans for eight teams working in three countries!

After the day it was quite clear that this will be a practice we will keep on doing. Personally I was really happy to see people take this seriously but with a small twinkle in their eyes. People participated, teams got their Release Plans and people from business and development worked together. In the end, I believe that's the essence of Agile Software Development.

Some things that were left for the next time: estimating the business value of the release objectives and things regarding the architecture vision. Also worth considering if this could be worth spending the full two or one and a half days on the topic. At least I think it's better to have it in one go than to plan for weeks.