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.

Technology Adoption Life Cycle

I'm currently reading Crossing the Chasm by Geoffrey A. Moore. I have already before heard about the Technology Adoption Life cycle, but I've learned plenty of new things about it from this book.

Technology Adoption Curve

Figure 1. Without the Gaps.

Many times the technology adoption life cycle is presented as in Figure 1. Certain percentage of people (statistically) belongs to each of these groups. Only a very few belong to Innovators. Together with Early Adopters they make the early market. Early and Late Majority make 2/3 of the total sum. They form the Mainstream Market. And finally about one sixth belongs to the Laggards.

But actually this Bell curve isn't continuous. There are bigger and smaller gaps between the groups and that's where the interesting part begins. All the gaps have significance, and you need to change your approach when dealing with different groups, but the most significant gap is between Early Adopters and and Early Majority. That's why it has deserved the name Chasm.

Figure 2. The Chasm between Early and Late Market.

One thing that separates the different groups is that they are looking for different gains. And thus they cannot be used as references for the other groups. In the following I'll try to summarize what are the minimum requirements to make buying easy for the target groups. Figure 3 also contains information about in which order your company should focus on the different topics (Technology -> Product -> Market -> Company).

Innovators are interested in technology just for its sake. They are constantly looking for new things. Most probably you don't find them, they find you. They are willing to accept even buggy product, but they want it to be something totally new.
How to make buying easy: They want to be able to name it and understand what category it belongs to.

Visionaries (or Early Adopters) aren't as technology oriented. What they want is a big performance boost. Something that has not yet become mainstream and they can truly exploit before it becomes common knowledge. Usually Visionaries are career rockets and not people who are looking into spending the rest of their career in their current company and position.
How to make buying easy: They want to know who is going to use it and for what purpose.

Pragmatists are not looking for such big performance boosts. They want the new thing to replace something existing and doing that in a slightly better way. When they look for references, they want to see other Pragmatists. They are not willing to weed out any bugs, they want the product to simply work. Pragmatists and people in the late market want to support and buy from the market leader. They don't want to back up someone who might be going out of business.
How to make buying easy: They want to see competition and want to buy from the market leader.

Conservatives or the Late Majority will wait until they need to get that new thing. When they cannot do business anymore without that certain something. Usually they aren't that interested in technology. They might even be a little afraid of it. They will tolerate technology when they don't need to think about it.
How to make buying easy: They want to buy from an established company that can stay in the game also in the future.

Laggards aren't usually buying. But they can try to intercept your sales attempts. Try not to give any fuel for their fire!

Figure 3. Competitive Positioning Compass.

Whole Product

When you sell the product, the customer will form a mental image of it. Your sales promise most probably doesn't include everything your customer is expecting but you will none the less need to fill these expectations. In the below figures Generic Product represents the product as you have it. To be able to penetrate the mass market, the product must be supplemented with many other things and services. Only thus can it become a total solution, or in other words, the Whole Product.

This was only a short recap of some of the ideas I found in the book. As for any other book, if you got interested, please read the original. I really liked Crossing the Chasm. I look forward to reading Escape Velocity next.

Tipping Point

After reading Malcolm Gladwell's Blink, I instantly became a fan of his work! So when I was last time buying new work related books from Amazon, I also got Gladwell's Tipping Point. Here's a short review of some main concepts I found interesting and maybe worth remembering. As always, best experience is achieved by reading the book yourself.

A lot of the book is about epidemics. What makes some things spread and why. There are certain factors that make it possible. When the stars are right, the epic can reach a tipping point and spread like a wild fire.

The Law of the Few

First interesting idea is identifying special type of persons. Salesmen, Mavens and Connectors are not like the rest of us and their role in making something to tip is crucial.

Connectors are people who are extraordinarily well connected. They know a lot of people and are eager to meet more. Many times they are people who have a leg in many different circles. And they genuinely like other people.

Mavens hoard information. They are eager to spread it and keen to learn even more. They are the people you naturally go to when you need to know something.

Salesmen are charismatic people who can persuade. They have an innate gift that makes people want to agree with them.

The Stickiness Factor

In addition to the message carrier, the message itself makes a difference. Rumors are sticky and spread easily, but boring stuff escapes ones mind rather fast. Many times the message can be modified to become more sticky.

Including a map of campus increased the change for students to get vaccined. Sesame street was at least originally created in a way that children find it easy to follow. For children it's critical that they can understand the plot in order to keep them interested. If characters are having adult conversations or using language they don't understand, they easily lose focus.

Teens don't smoke because smoking is cool, but because smokers are cool. Many times smokers are seen as rebels, sexy and interesting. So actually some smokers are like Salesmen for smoking. Interestingly whether someone becomes a nicotine addict has a strong correlation with how the first experience was. If it was pleasant, there's a big change the person can get hooked. (Okay, this might be obvious, but still interesting.) Also there seems to be a tipping point to smoking. If you smoke less than certain amount of cigarettes a day, you can go on for years without getting heavily addicted.

Power of Context

Whether we are discussing a contagious disease or an idea, context plays a critical role. Theory of broken windows states that enviroment affects people's (criminal) behavior. If you let one window break, it is kind of an invitation to break more. Same seems to apply to graffiti and small criminal acts. If you can weed out the small criminalities, according to this theory (and as is seen in practice) it will decrease the number of more serious crimes. In software development one could replace windows with a build. If you don't keep your build green, you are asking for trouble.

Dunbar's number, ˜150, seems to have a special meaning for us humans. According to different studies it is the maximum number of people we can feel connected with. With that many people you can have personal relationship in a company. After that limit is exceeded, things tend to get more complex. (Fun fact: it's a also the limit for SAFe Agile Release Train size.)

As a final remark, the role of the family is not as influential as we generally thing. Who you hang out with makes a bigger difference. So it's much better to grow in a lousy family in a good neighborhood than in a rich and loving family in a bad neighborhood.

Getting some idea to a stage of epidemics can be engineered. You need to take into account all the three factors and it probably isn't easy, but I'm positive that it can be done. Successful advertising companies have done this multiple times. Again, slightly disturbing, but good to keep in mind.

Problems in Working Together

Maybe from my posts people can get a false idea that everything always goes as planned. Well, it sure isn't like that. In the following story there's plenty of lessons to learn and things to improve.

Two Teams

There were two teams working on a legacy product, let's call them team A and team B. (There were other teams too, but these teams are starring now.) Team A was working on the very core services and low level functions that other teams, including team B, depended on. Due to the fact that automated code coverage was not on very high level and the code base was really complex and not in mint condition, there were many times moments that things broke down even though all automated tests passed. And because team B was working on the application layer, they often found these problems. And they suffered.

Team A did mistakes. But they were always keen to correct their mistakes and open about development ideas. Approaching them was easy. You could walk into their team room and just state your business or ask for help. And they would help you out for sure.

The working model for the teams consisted of fixed deadlines. On a specific date things were to be done. Prior to this date was a so called stabilization/freezing period that was dedicated for bug fixing and testing that all parts of the complete system worked. One can imagine that closer to the deadline pressure was increasing.

During the stabilization period team B was blocked by some defects. They didn't proceed in testing because they didn't want to test same things again after the fixes would be completed. Unfortunately team B didn't make things easy. Usually they approached team A with JIRA issues. And we are talking about teams that handled plenty of issues a day, so prioritization and keeping track of all changes was a challenge. So sometimes it happened that the issues did not progress very rapidly.

At the time of deadline team A was done with their testing and didn't saw major blocking issues. Team B was about halfway done and still had issues open. And they were complaining that team A was blocking them. In the end both teams ran out of time and the common product was not releasable in time.

In Hindsight

Both teams made mistakes. One of the major ones was communication. In a small organization it should be more than ok to use the Adidas-method: walk to your colleague. Don't keep things in a desk drawer. Let the other person know about the problems in a timely fashion. Don't rely only on the tools.

Another major mistake is relying too much on automated tests if you have low coverage. I think it's a sure recipe for disaster. If your code coverage is 35 %, it means there's still almost two thirds of your code that needs to be tested manually. It is laborous, time consuming and demotivating, but it's a must if you don't want to give out buggy software.

In our setup cutting scope is possible. The rule of thumb is that schedule and quality are fixed, but scope flexes. This principle was not obeyed and the scope was not adjusted in time. And quality debt had been accumulated during development resulting in big amount of late bug finds.

Finally the whole fixed schedule model can be questioned. Is it the practice that creates most reliable and high quality software? Of course continuous attention to quality, vigorous testing and cutting the scope in time will make a big difference. But most of the time people are weak and things tend to take all the available time. I have started to lean more and more towards concentrating on getting things done and letting the schedule flex a bit.

Another text book answer would be that if something is difficult, you should do it more. If it's hard to keep three month deadlines, cut the time in half or even shorter. Then you will iterate more rapidly and get better faster. I'd like that too.