Horizon 3 Development

The following post is not that directly concentrating on software development, but more in the early stage business development in B2B field. The learnings here seem to apply to domains that are a bit slow moving, like maritime and telecommunication. Maybe they can be applied more widely, but I have no first hand experience from others. Would be interesting to hear your thoughts if you have similar experiences from other business fields.

 McKinsey's three horizons is a framework for categorising businesses that are in different stages. 

Three Horizons

Horizon 1 (later H1) is a steady running mature business. One that is no longer growing much, but generates revenue steadily. Aim in this business is to maximize profitability. 

Horizon 2 (later H2) is growth business. It is not yet necessarily profitable, but the engine of growth has been found and there's a good product-market fit. Aim is to maximize the growth while there's still market left. At the later stage the goal is to make the business profitable a.k.a become H1 business.

Horizon 3 (later H3) is new business. Usually far from profitable, maybe even no customers at all. In this category useful metrics can be found from Lean Startup. In theory companies would like to minimize the time spent in H3 and skip this part with as little effort as possible and become an H2 business.

One can see similarities in the three horizons model and Technology adoption lifecycle model. The early adopters are willing to try new things and are willing to accept some 'children's deceases' in the products partially for the possible edge they can gain from the new innovation, partially for the sheer value of being seen as pioneers or forerunners.

The Problem in H3

The problem is that one cannot advance from H3 to H2 without really having a solid, scalable solution. H3 customers might be willing to have a proof of concepts, co-develop or co-create a solution together with the solution provider, but usually customers at later stages are expecting more maturity. And there are two options: you build the basis for scalability while you are still seeking the product market fit with your H3 business or you are late and will have huge delivery pains at the beginning of your H2 journey.

Needless to say, the problem is not that trivial to solve. H3 businesses are usually startups or internal startups with limited resources and budgets. Time is their biggest enemy, because time equals salaries and other operational expences and with a long time to market you probably lose the opportunity window and some competitor gets the customers. The time constraint is the reason companies do sub-optimal design choices that result in non-scalable architectures. Instead of taking the extra time to do things properly, companies take technical debt. And when you reach the growth phase it might be really difficult to find the time to pay the debt back.

What to Measure

In my experience (B2B software development in telecommunication field), the biggest bottleneck is not software, it's customer access. The metric I propose to follow in H3 phase is how deep customer relationship you have been able to develop.

• How many meetings you have had with different people in the customer organisation?
• What are the roles and ranks of persons you have been interacting with?
• How precise questions they have asked?
• How well have you been able to understand the customer's business and identify the customer's painpoints and problems?
• Are you able to provide them with something that helps them
  a) save money
  b) get more money
  c) help them do something they couldn't before

Deepening the customer relationship takes a lot of time. So does finding new customers. That's why testing your ideas might be really slow compared to working in B2C where you can more easily reach many customers (although I'm aware that it is nowadays really difficult to get consumers attention). Keep track of your progress and you are able to make decisions based on data!

New Agile Framework

I have been involved in agile software development for quite a few years now, and for the last couple in various process oriented roles. So, I was really excited when I was involved in defining a new agile methodology. The first thought was that why do we reinvent the wheel? Why not simply use Scrum, SAFe or something else? But, taken into account the environment (which I'll soon explain), it could be feasible to come up with a new one.

In this case we are not simply working in a product development organization. Many times the job sizes are so small that they don't require a full team. And by far not big enough to use Scaled Agile Framework. There are multiple smaller customers and work includes both development of new solutions and maintaining old systems. Very complex setup.

Dealing with multiple customers in different software development lifecycle stages is a very complex problem.

Some basic principles that were not to be negotiated:

• Teams. There needs to be some basic unit to share the work with.
• Autonomy & self-organization. The teams need to be able to organize their work. And the developers decide HOW things are built.
• Ownership. Teams need to own their results. This is why a large amount of craftsmanship is needed.
• Transparency. Everything should be open. In my experience transparency always improves quality.
• Backlog management. There should be one person who has authority over the job queue. The same person will represent the voice of the customer.
• Continuous Improvement. Teams need to examine their working methods regularly. Measurement enables feedback and thus learning.

In practice there are two types of teams. Some handle the larger customers. Mostly one team can serve a couple of bigger clients. This way they can have internal job rotation (which is refreshing) and still there's continuity in the customer relationship. And even if there's a slower period with some customer, the team can focus more on the other. The knowledge is kept alive and there's flexibility to answer variance in demand.

The team members will learn to know each other and work together. Increasing the level of trust will enable better working methods and slowly but steadily one plus one will become more than two. Restrospectives will help the team learn.

For the smaller customers and new gigs there's a special team. In a way the work with bigger customers is easier and you can have more junior colleagues learning the ropes from the seniors. But when there is a vast number of customers in maintenance mode, you can only cope with seasoned professionals. And you need to maintain a decent level in documentation. When the panic strikes, there's no time to start looking for instructions. You need to have clear plans and a solid map to navigate the environment.

All in all, although SAFe was developed for big and complex environments, I feel the problem with only one production and mostly one product is much easier to crack than the one I'm currently dealing with. And that's why it's so interesting!

SAFe deals with a relatively simple problem: one product.

One concrete challenge when you introduce something new is the unlearning of old ways. Many times people are biased, even if they don't perceive it themselves. And of course it's tempting to accuse the new framework about all surfaced problems. But recovery can only begin after admitting the facts.

By the way, I have written another blog post about this new framework in Elisa Hub (unfortunately only in Finnish). Feel free to check it out too.

It Yourself Framework Do

As the saying goes, one picture tells more than 1000 words. Maybe that's why there are these comprehensive frameworks that offer nice pictures that you can click and get even more information. There's one in SAFe. And another one in LeSS. And of course DAD has one too. After checking all these others I was actually a little disappointed that Pragmatic Marketing framework does NOT open up the same way. (Improvement suggestion?)

Since many of these frameworks are copyrighted and no modifications are allowed I'm not going to propose anything like that. But, if you have internal processes or any other information that is dispersed in multiple locations and you would like to visualize them in a similar way with these frameworks I'm going to teach you how to make a poor/lazy man's version of the same. You will need the following tools:

• PowerPoint
• Some picture 
• Documents located at some internal/external URLs

Because today is #StarwarsDay (#MayThe4thBeWithYou), let's use something related as an example.

First, create a new presentation and add your favorite to-be-framework-background picture to the slide.

Then add the first hyperlink location. If you want to use really fancy shapes, be my guest, but I'd recommend simple ovals and squares.

Draw the shape on top of your background image. Then modify both Shape Fill and Shape Outline to be invisible (No Fill, No Outline).

After this you simply add an Action to the shape that opens the specific URL. I recommend also using the highlighting to more easily spot the actionable area.

 

Because I had nothing special in my mind I just used Google to find out what can be found with 'Yoda's Eye'. Turns out there is a metal band with this name. After inserting this link and starting my ppt-presentation the result is the following:

The same step for all your relevant links you repeat and a really actionable internal framework get you will! May the force be with you!