Release Planning With Customer Focus

I've written about our Release Plannings already (here, here, here and here), but maybe there's still something to add. These blog posts also help me understand how things have evolved over time.

This time we had agreed the Release Planning Day, our common company event, would only serve as a deadline for having the Release Plans done. So all the actual planning was done before hand. One tool that we extensively used was Microsoft Yammer. It has proven to be handy for sharing something get insights from different stakeholder around the globe. In addition there was a lot of face to face planning between the Product Managers, Product Owners and Development teams.

I had split the day's agenda into the following parts:

• Agenda and purpose of the day delivered by Release Train Engineer
• Where We Are Heading, market insight and Portfolio funnel status by Chief Portfolio Officer
• Product Roadmaps by Product managers
• Lunch and team break
• Each teams' finalized Release Plan by Product Owners
• Launch Plan for each product/solution by Product Managers

I think out of these probably all other items are familiar from SAFe except the Launch Plan. And actually even that is in SAFe. There the name is simply Release. But in our company lingo we have used the word Release for both the Potentially Shippable Increment (PSI) and for the actual Release.

Previously our Release Process ended when the PSI was done. Development and releasing were decoupled. Although this is often beneficial, it had proven to generate a lot of confusion. Sometimes we had a PSI, but no plan on what to do with it. We had concentrated too much on the technical side and forgotten what our whole system was supposed to do: provide our customers with new increments of working software and added value.

Launch Plan is an attempt to look at the same topic, Release, from the customer angle. In bare minimum I want the Launch plan to answer these questions:

• Who are the target audience for this Release?
• How will we communicate about this Release to our target audience?
• How will we deliver the Release to our customers?

Also the Launch Plans seemed to reveal interesting new things about the organization. What we talk about as Release is usually just release of the software component. Creating the PSI doesn't take into account how it will be delivered, configured, trained to new users or marketed. All these are really relevant topics and especially relevant for the customers.

I think generally the Release Planning Day was successful. It was shorter, more focused and took the customer view better into account. In short I would claim it was the best release planning we have ever done. But just as a note for if you plan to try this in your organization: this wasn't our first time. Without the shared history and previous steps on our path I don't think it would have gone like this. So don't try this at home. (Or who am I to decide. Maybe this is the killer recipe that works as a silver bullet. I've tried it once and it worked for me. :) )

As a main takeaway for next time I think we'll be increasing the cross functional collaboration and trying to take all relevant functions into the game, not just development. I think by tweaking our system we can reach so much further than where we are today!

Release Planning in One Day

In this blog I have shared experiences of our Release Planning Days. Of course the first one was most memorable since back then everything was new and exciting. Second attempt proved that it wasn't pure luck, but that the concept was actually working. I documented also the third one, but after that I thought that it maybe isn't that exciting anymore.

One unfortunate thing to mention is that the day was a public holiday in one of our offices. But quite a few of our colleagues from that site were willing to come to work on that day and get another day free in exchange. I call that going the extra mile.

But maybe I can tell about the most recent attempt, since it was again a bit different from the previous times. For our latest Release Planning I had given some of my colleagues a few chores to fill in advance. Here's the list:

• Portfolio Backlog is in presentable state
• Product Managers have discussed their the Roadmaps with teams working directly with them
• Product Managers have made an initial Launch Plan for their products
• Product Owners have crafted Draft Release Plans for their teams

Out of these, the first task went to our Chief Portfolio Officer who is like the Grand Vizier of the Portfolio level. Second and third tasks went to Product Managers (Program level) and the fourth one to the Product Owners (Team level). 

Launch Plan is a term that isn't originally from SAFe (as far as I know). It communicates the intended usage of the Release if and when it would be successful. Previously we had identified a waste of extra waiting time when the Release was ready, but we had not decided what to do with it. The accompanied business needs are in most cases clear already when the work on the release starts. That's why it is practical to craft also a plan about the usage. And if something is left our the Release scope, the plan can be adjusted.

So, in essence we skipped the first Team Breakout. Also the organization of the presentations was modified. In our past Release Plannings all Product Managers have presented their Roadmaps in a row. But since we had the Draft Release Plans already available at the beginning of the event, I wanted to form logical entities of the Roadmaps and associated Release Plans. This also helped in focusing on one subject at a time.

The morning part of the day was heavy. That was clear already beforehand. But we didn't come up with any better alternatives. At least grouping the presentations in the new way was seen as an improvement.

All in all things went pretty much as expected. During the Team Breakout some plans were modified but most of them were almost the same as during the draft phase. The new, more compact way of conducting the day seemed to work well and we will probably do it like this also next time.

Practice Makes Perfect - Release Planning Day 3

It's an amazing feeling to notice that something you have deeply invested in has started to become routine. Not for you, but for the organization. I had the pleasure of experiencing that today.

We had our third Release Planning Day. I've told more in detail about the previous two times in my earlier posts. This time the agenda was pretty much the same as on the previous try. Day began with a look at our markets and business. I like to see how things are connected. It's easier to justify your daily work when you can fit it into the big picture. What ever actions we might take should in my opinion bring us closer to our Vision. The message was delivered by our Chief Portfolio Officer. (SAFe model suggests getting some high ranking executive to signal the importance of the meeting. I think we've already seen the usefulness of Release Planning but it doesn't hurt to have powerful people involved.)

Then our five Product Managers presented their updated Product Roadmaps. Most of the contents in the Roadmaps were pretty much the same as last time. This makes sense since the Roadmaps should cover long term development needs and shouldn't maybe live as much as the Backlogs. There were some comments which I hope spawned even more lively conversations after the meeting.
One impressive moment was when I realized that we have around thirty people sitting in Helsinki and the PM presenting his Roadmap from Asia over Lync. And you really could not tell much difference from a case that the person would have been there live. Except for the fact that one couldn't see him. :)

After the Roadmaps I gave brief instructions on what I expected us to achieve during the rest of the day. Then people simply disappeared. Almost before I had even finished talking. But that was good. They knew what to do and were determined to do it.

During the Team Breakout session I wandered around our premises. That was the second time a slight smile suddenly appeared on my face. There were groups of people here and there discussing the coming Release. Exactly those necessary conversations that need to take place! What should we do? Why should we do it? How should we do it?

Later in the afternoon we gathered back to the meeting premises and went through the Draft Plans. Each team had come up with a list of topics they will start to work on in the next Release period. Already many cross-team issues were identified and the plans were well in line with the Product Roadmaps.

Tomorrow we will go through the finalized plans. I'm not anticipating any big changes so we will probably just go through the main changes compared to the draft phase. But all in all, everything has worked so far just as well as one Release Train Engineer could possibly hope. But of course next time will be even better. Continuous improvement!

Second Release Planning Day

Before the summer I wrote about our first attempt to do a whole company Release Planning Day. Since we do releases in regular cadence, now was the time to try this activity again.

After the first trial I had received feedback that doing everything in one day was maybe a bit too overwhelming. One concrete remedy was to divide the activities to two days. Another improvement that I was happy to witness, was that this time the Product Managers really prepared for the event. They discussed and worked on their Roadmaps together with the teams during the past couple of weeks. And this activity really paid of in the quality and in the level of realism.

People took the event seriously. Even though one of our Business Owners and a Product Manager were visiting customers abroad, they took the time to do their part in the agenda. Their presentations were broadcasted over a VOIP connection. But for me the message was clear: this event is really important.

The first day started as during our first time. The schedule for the day had been delivered to everyone already via email, but I briefly revisited the agenda. Then our Business Owners gave an overview of the market situation. What is happening now and how we should prepare for the future.

Next the Product Managers shared their Product Roadmaps. We are still working on these and lot had changed since the last Release. Mainly many not-so-well prepared themes had been dropped and returned back to the funnel stage. There were clear pros and cons for this approach. Now the organization was able to focus the attention on the few Epics, but on the other hand, the longer term visibility was missing from the plans. But I'm confident we can work that out in the future.

We are still figuring out our Architectural Runway and how to coordinate it on the Program level. But as the manager of our System Team, I used some time to tell about the tool changes we are about to carry out during the coming Release Period.

After the common sessions it was time to split into teams and start forming the draft plans. Teams collaborated with the stakeholders and tried to formulate the needs of the business into a realistic set of PI Objectives. Actually, in our company language we call these Epics, since that's how they are called in JIRA Agile. The lunch hour was also incorporated into the first Team Breakout.

The next common session was the Draft Plan Review. Every Product Owner presented their team's draft Release Plan. This way it was easy to spot if something was missing or required coordination with other teams. There were no major surprises. It was as if people had actually discussed their plans together. Oh boy, who could have seen that coming!?

After the Review there were two options. Teams could continue planning today or go home and rest. The next common session was scheduled for the morning of the next day. Since we have development team members in multiple time-zones, I thought it was ok to offer possibility to carry on the planning on one site and pick up earlier on the next morning on the other site. Also the splitting gave people more time to do the planning. And at least I felt rather exhausted in the afternoon already.

I don't actually know how the teams decided to do. Maybe some continued the planning, maybe some went home early. Anyway, the next morning we gathered again to a common session to go through the finalized plans. Most of the plans had not changed much since the draft phase, but I believe it was good to have time to digest them a bit and work out the dependencies if any. There were still some questions and comments but generally people were satisfied with the plans.

In the end I wanted again to have a vote of confidence for the plans. Just so that nobody could walk away from the event and say it was not their plan. At first it felt a bit silly. And it was. So in the end I turned holding the microphone to the crowd and yelling "DO YOU BELIEVE IN THIS PLAN!!?" And they did. :)

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.