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.

Software Development - More Than Coding

Think about software development. I'm assuming you have an image of someone writing code in your mind. Well software development is that, also. But it's also much, much more.

In my company I'm responsible for the software development in this more broader sense. When I think about software development, everything begins from the customers. Developing software is solving customers' problems. Selecting what problems to tackle as a company is a strategic choice. Strategy narrows down what you develop and helps the company focus. Probably it also states in which markets you want to compete in.

Strategy helps the company define it's portfolio. What customer problems we want to solve and what kind of solutions we offer? The solutions can be products or services. Strategy should guide you in this. If it doesn't, refine the strategy.

Let's now assume that in your offering/portfolio you have product(s). Each product should have a vision. What the product will be in the future? What customer problems will it solve when it will be in it's ultimate, final form. (This form will never see the daylight. Vision serves as a distant goal, something to strive for. It's an idealisation that will be even more magnificent when you get closer.)

Vision will help you define a roadmap. Where as vision can be hazy, the roadmap should be really concrete and tangible. I think of roadmap as a guidebook for the next steps toward the vision. If your strategy is planned for the next 5-10 years, roadmap could cover maybe 3 years. It's worth noting that it's still a high level plan and as for any agile plan, subject to changes.

In software development roadmap is implemented in releases of new software versions. They are usually developed in iterative and incremental fashion. Old functionality is modified and improved with new features and bugs and defects are fixed. Many times companies try to shorten their release cycle. The ultimate case would be Continuous Deployment where every change would be deployed to customers. But this is very much industry specific. In some cases the overhead of taking new software version into use is so big that customers don't want to do that often. Then it's practical to select a release cycle that suits both the company and the customers.

In agile development, software is usually created by small teams in an iterative fashion. The length of these iterations or sprints is usually limited to less than a month, a little bit depending on the selected methodology. Sprints are like mini-projects; they are planned, executed and in the end there are sessions for examining the results and for learning from the experience. ...and then cycle starts over again.

Daily work in sprints is carried out by the development team. Developers are experts in their field and select the most fitting methods for the implementation. They have the authority for carrying out daily decisions.

We got to the part where the coder writes source code. But as there are many layers in onion, there are many layers in software development. Writing the code is just one of them. Never the less, it's an important craft if the software is to be of any use and even more so if it is to be maintained.

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.

Successful Pre-Planning

Sometimes things just go smoothly! Today was one such day. Today was the Pre-Planning of our next Release. Everyone was well prepared. As I have previously written, we are currently experimenting with Scaled Agile Framework (SAFe). We have Product Visions and Roadmaps. This is an area where we have especially put our efforts on lately and it really starts paying off!

We had a two hour session. First some general information about the schedule and then introduction to not yet so familiar concepts of Themes and Roadmaps. Then the Product Managers introduced their latest Roadmaps and explained the business drivers. It was nice to see the leap in the quality since the previous Release.

After the Roadmaps, the Product Owners shared their teams' draft Release Plans. Some of them were not yet very realistic or contained way too many things, but it was good to have visibility to this none the less. Seeing some draft gives a lot more possibilities for improvement than having nothing at all.

Hopefully this two hour event gave the whole company a better view on where we are and where we want to go next. As the coordinator and facilitator of the event I felt it hit the spot. But I have a tendency of being over-optimistic from time to time. ;)

On a side note, I finished reading Management 3.0 by Jurgen Appelo. Great book! I can already see myself trying this stuff in action.

Facing the Reality in Product Management

For some reason Software Development is somehow so far from the physical world that it is very easy to neglect the truth for a very long time. Managing products is one area where I have faced some horrendous gaps between the plans and the real world.

This picture of Chinese traffic jam has become one of my favorites lately:

Unfortunately I think it characterizes the amount of things some people think can be done in parallel. A Product Roadmap that has nine things that should be developed in parallel. By one team. Of about nine persons. If you say it out loud like this, it's probably evident that it's not going to happen. But if you just add boxes to a PowerPoint, it's deceitfully easy to just add one more box. ...and yet one more.

My solution asks for another picture. 

"There you go. I think your Roadmap is great, but it only has this one flaw. Everything you have there needs to fit through this funnel." Well the diameter of the funnel of course depends on the team size, but I think one-piece-flow would be something to strive for.

Doing things in priority order one by one. Creating the features that offer the biggest customer impact and added value one after another. Doing things pragmatically and keeping the focus. Let's try to get there!