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.

What's (Still) Missing From SAFe

Scaled Agile Framework offers a nice collection of Agile best practices. The Big Picture helps to visualize different concepts and ways of connecting them together. But one thing has always bothered me: there's no Customer in the picture. That's why I was positively surprised to read that the new version 4.0 will include also this one missing part.

I guess SAFe is mostly describing practices for the research and development activities. But once the development is completed and it's time to make a release, you usually want to give it to your customers. And in most companies there are functions that operate more closely in the customer front: sales and customer service. In smaller organizations these activities could be handled by product teams, but I assume that in a company that is big enough to benefit from the Scaled Agile Framework, these functions are separate.

Actually, linking the development with sales activities is a non-trivial task. I would maybe first broaden the scope of the Product Management with practices from other frameworks, for example Pragmatic Marketing Framework. For me the sales activities are essentially trying to identify customer's needs, understand their problems and look for solutions to those in co-operation with them. If the current offering can fit the customer's process as it is, that's great. But as good solution could be adding the customer needs to Backlogs and fulfilling them in the future. And developing them together would make sure they fit their needs.

Another addition that I would like to see in SAFe is the role UX and design. In the article about Sprint Execution, there's the DBT (define, build, test) loop. I don't think that's enough anymore. I would like to bring this more towards the direction shown by Lean Startup, Lean UX and Design Thinking. Testing should happen with real customers to validate the hypothesis made before the development. Otherwise the road to hell can be paved with good intentions. You might assume that customers want something, but without testing your idea in practice you could be on a totally different page. (Actually I first missed this SAFe UX article. But I think it should be brought more to the Team level also.)

So those are the couple of additions that I would be glad to see in the future. Without Sales there's no money coming in. And without good UX there's probably no sales.

Do the Right Things Right and Fast

It's fascinating how sometimes some relatively simple picture can contain so much relevant information. I have been lately involved in strategy renewal and while doing that I saw a picture that I fell in love with.

My job is very much concentrated around improving software development processes. In essence it's about doing the things right. But many times I have thought that it doesn't really matter if you do things right if they are not the right things. You might write the most beautiful and simple code ever, but it makes no difference if no one cares about it. I feel this is often a problem with some open source projects. Okay, there might be open source with crappy code quality too, but usually the quality is on a really nice level.

Another case are commercial projects with tight deadlines. In those cases it's easily right things (someone, usually customer, is really interested about the results), but just fast. When coders are stretched, it is the quality that suffers.

By concentrating on the software production methods (Continuous Integration, Continuous Delivery) and good engineering practices (craftsmanship), one can only reach adequate results. One dimension is still missing.

Maybe the best non-perfect position to be is when you have a good portfolio (you are doing the right things) and you concentrate on your code quality (doing the things right). At this point you can still miss valuable market windows, but it can still work. Then you can start investing in the production methods and speed things up until you hit the sweet spot in the intersection of all the three dimensions.

I thing this later triplet of circles depicts the situation at practical level. When your Product Management is working properly, your Developers are applying good engineering practices and your development infrastructure is in order, you can expect awesome results. I'm not saying it's easy to achieve but definitely worth a try.

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!

Focusing is Effective

If you have a hypothesis, there's probably no better way to validate it than by testing. It's one of my favorite practices from Lean Startup. Experiment. Make a hypothesis, test it and learn. Repeat.

But you also need metrics. Something that you can measure and see if your actions have impact on them. In our case we have been asking our Developers, Product Owners and Product Managers the same set of questions twice. (The poll has been anonymous and people have been participating really well.) The results show nicely how the actions we have done (our focus) have improved the results in those areas. Unfortunately they also show that things that have not been paid too much attention to are not improving.

We have made big efforts to improve our Product Management and to shed more light to our Product Portfolio. Also we have invested in training our Product Owners. The results in these areas are almost stunning. According to POs and PMs the work in Portfolio has improved by 30-40%! I could call that from zero to hero. Developers are now more satisfied with their Product Owners. Although the sample size with Developers is lot bigger than with the other two group, the numbers have gone up by almost 14%.

But unfortunately there are two sides in a coin. While we have put a lot of emphasis on the Portfolio and on Product Owners, we haven't maybe paid enough attention to core of the agile. Data is ruthless and clearly shows that our efforts in Continuous Improvement and Visibility to Work have not been too good. For this I will take personal responsibility. I'm currently both Chief Scrum Master and Manager of Releases. I have been clearly concentrating too much on one part and neglecting my other responsibilities for the organizational improvement efforts and making things visible. Point taken, now I know what to improve next.

As a statistical experiment this has been very interesting. My interpretation of the results is that they validate our hypothesis. The areas we concentrate on are affected and in a positive way. Having focus does pay off!

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.

Scaling Agile Peer Conference

Agile Finland arranged a nice peer to peer conference around Scaling Agile. Venue was Life Science Center in Keilaniemi, Espoo. First of all I have to say that facilities were excellent. Top floor sauna with a sea view.

Participants had been pre-selected and there were people from eight companies. All the participants were required to write an experience report about how they had scaled agile or transformed the organisation into a more agile form. The seats were arranged so that everyone could be in eye contact with all the others and discussion was very easy. 

The day was packed rather full. We started already at 8:30 in the morning and finished around 17 o'clock in the evening. As we agreed not to share too much about each others practices and processes publicly, I won't get into details. But some interesting topics/practices I dare to share were the 24 h hackathon, group Backlog and a team building event where people had to self-organize into teams. Also, a topic that was common to almost all the participants was the Product Management. That's the not-so-trivial interface between business and development. Maybe that's the unicorn of Agile. ;)

I'd like to mention a very interesting facilitation technique called Open Season. Everyone had four cards: green, yellow, red and blue. Green indicated that you want to start a new discussion thread. Yellow meant that you still want to add something to the current topic. Red meant that you need to speak right away and blue that this is boring and let's move on. Red and blue were never used, but otherwise the conversation worked very well! Actually you can find a rather elegant guide on how to arrange a peer conference from this blog entry. I think we followed it very closely.

My best take homes were definitely the new contacts. Hopefully we can grow even more agile together! Also it was nice to get to know how other companies have been scaling agile. And by the way, if you ever think of arranging a conference like this, think no more. Do it! It will be great.