How Epics Flow Through Our Value Chain

If you are familiar with my previous posts, you probably know that I'm a Release Train Engineer. But as I've told, that's not all I do. Nowadays I'm not anymore Product Owner, but instead I try to concentrate more on being an owner for the value chain. So let me next try to describe the flow from idea to implementation.

When new (big) ideas are introduced, there are first a few prerequisites. There must be a business case. When we plan few years ahead, the idea must be profitable. Forecasted amount of revenue must exceed the direct development costs and the future maintenance costs. We also need to analyze roughly the size of the effort and amount of resources needed. Checking the time criticality and whether we have the capacity to squeeze the job through our pipeline in time are essential factors. It's also practical to check if the idea is in line with our strategy in general.

When all necessary groundwork analysis is done, our Portfolio Managemenent Team will make either a Go or No-Go decision. If the idea is approved, it will be added to a product Roadmap and scheduled for development. At this stage the idea is called Roadmap Theme. In SAFe the corresponding term is Epic.

The Roadmap Themes enter development through Release Planning (PI Planning). They are broken down into pieces that can be implemented within our release cycles and formed into JIRA Epics. After that the Scrum teams will further refine the Epics into Stories and tasks. Then they will work on them in an iterative and incremental fashion in Sprints.

Then comes the part that SAFe (to my knowledge) doesn't answer anymore. As in Scrum, there are lots of activities left for the organization to figure out. Also for releasing, there's usually a lot more than creating the software package. Even if you have managed to get your act so well together that you are practicing Continuous Delivery or Deployment (which we are not), you still need to communicate with your customers. People don't like surprises. Even if the changes are improvements, many times people will get pissed if they didn't know about the changes or asked for those.

For me the final touch for releasing are the accompanying activities. Do we have the marketing materials ready? What do we tell the customers? How do we sell them, whats the story? Sometimes we might need to train people. Or the very least we need to let the customers know about what they will get. And we need to distribute the same information internally. Otherwise communicating the new added value might be really difficult.

Product or solution might be only one layer inside a big onion. For some companies it's even relatively tiny compared to all other things. For example Supercell uses over 400 M$ on marketing. I don't think the budget for game development was anywhere near that sum.

In practice (in our setup) all these different activies for an Epic should be lead by Product Manager. S/he isn't the one who should do everything, but make sure they happen. As a Release Train Engineer and Value Chain Owner I try to ensure this happens. It is maybe worth mentioning that through SAFe, the activities related to writing software are rather well formulated and established. The cadence based thinking still needs to be implemented for these other activities.

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!

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!

Planning Releases

I believe I was just getting the hang of this Scrum thing and I thought I could do some decent Scrum Mastering. But now the things have changed slightly and I need to jump "over the fence". For a bit over a month I've been working as a Product Owner and a Release Train Engineer. I can see that it's actually a lot easier to identify missing Product Owner as an impediment than to actually be the Product Owner and try to live up to the requirements of the role. There just doesn't seem to be enough hours in the week to constantly keep the Backlog in order and think about all the details. But maybe that's exactly the point. No-one is able to know everything in the complex world of software development and that's why letting go and giving the team the space they need comes rather naturally.

But then something about planning Releases. In Scrum everything happens around the Scrum team. Team forecasts what they can achieve during a Sprint and that's it. Achieved velocity, "yesterday's weather", helps to forecast what can be expected in a longer run if the backlog has been refined into a decent degree. But there's usually no mentions about what to do when you have multiple teams, multiple products, a bit of legacy and all in all a more complex situation than just complex.

I think Scaled Agile Framework offers nice way to see this from a higher level. Scaling to the level beyond teams and Sprints, I see Releases as a good logical logical next step. Also it seems like a good idea to set some higher level goals (or Objectives) that can be then divided into Stories when the actual work starts. Of course there will be some uncertainty associated with these goals, but I think they should be treated more as commitments than just some initial guesses that will be reformulated right after the first Sprint. Still, I don't support big upfront planning or waterfall. I just think that a bigger enterprise can't live without ability to plan ahead for longer than just two weeks.

Anyway, the actual planning of the Release is a complex task on its own. As the Release Train Engineer I wanted to arrange a so called Pre-Planning where all the teams share their initial plans and everyone gets some indication about what is to be expected. Then there will be time to work the plans out until everyone (or at least most of people) are happy with them. Then we can have can simply agree that this is the plan that we try to implement. And if it needs to be amended along the way, so be it. But the train will take off and only the future will show what's going to happen. ;)