Reaching the Next Level

When a new programmer starts writing code, s/he requires detailed specifications and clear requirements. The understanding is on a level "I need to get this piece of code working". There's not very much thought given on what happens outside this routine or how things are connected.

On the next level, the coder understands that the piece of code s/he's writing is a piece of a larger system. This system exists for some purpose, but the purpose isn't necessarily clear for the person. But generally s/he understands the system is important for the company and probably generates financial benefits (i.e. is sold).

Reaching the next level is already quite challenging. At this point the developer starts to think about the customers' business. How do the customers make their money? (...that can be then invested. Maybe in software. Maybe even on the solution you are developing...) And when you understand how the customers make money, you understand their priorities and needs. What is important for them and critical for their business.

There might be intermediate levels between the ones I mentioned, but I think this covers the basic steps. I'd encourage all developers to try to advance on these steps. The higher you are, the better you can fill your customers' needs and thus the more valuable you become. I'm not saying that code writing is easy. I'm simply saying that being able to write code AND understand the business is a tad harder and rare. Development on this path starts from understanding the user. 

(Sometimes the decision maker for software purchase is not the same as the user. Users might be only influencers in a complex network. But let's leave this out of scope for now. )

Sales & Teaching

Last week I participated in a value sales training (given by Talent Vectia) where I learned that 70 percent of sales representatives do not prepare for a customer visit at all. I could guess there's a correlation between this and deal closing resolution.

When customers meet a sales representative, they often think "Stop wasting my time." So don't. Make your visit worth their while. Things need to be communicated efficiently and clearly without too much fuss. And when you communicate with the customer, instead of talking about "waste", a better choice of words would be to make your visit "worthy" of their "valuable" time.

Another thing they look for is a chance to learn something new, a challenge. They probably meet plenty of sales people. Why are you any different? Challenge them! Don't make them too uncomfortable, but maintain a healthy tension.

Challenger is also the best performing sales profile type. It outperforms Lone Wolf, Hard Worker, Problem Solver and Relationship builder. I guess usually sales representatives

How to Set Up a System Testing Team

In my previous post I touched the topic of legacy modification. It is a difficult stunt to pull. Or well, in a perfect world with a well maintained codebase and outstanding automated test coverage it could be easy, but in reality I think that's rare.

One of the things that makes modifying legacy software especially difficult is the regression. When the system is strongly coupled, almost every little change can produce unforeseen consequences. (Yes, the Butterfly effect!) To counter-attack the diabolic regression effects your best bet is to invest in a test automation harness. But until your test harness is truly solid, you need to make do with manual testing.

In our setup we have two distinct periods: the Development period and the Stabilization period. During the Development period our scrum teams work normally in sprints. They concentrate on creating the new added value that has been agreed on in the Release Planning. Adding new code into the mainline is guarded with automated tests (unit tests + system level tests) and only allowed through pull-requests. Unfortunately due to the limited coverage, this is not enough to guarantee that things stay in good shape.

Development

Development

Stabilization

During the Stabilization period we stop adding new features and concentrate on testing the existing functionality. In practice this means testing manually those parts that are not covered by the automated tests. (This might be called classic hardening anti-pattern and frowned upon, but in this setup it's a must. New development meets Definition of Done, but it's the regression that gives us headache.)

Now this setup sounds a bit dumb. Why do we let the quality deteriorate and problems creep into the mainline and wait to be uncovered during stabilization? Wouldn't it be wiser to detect the problems early on?

Well, that's why we came up with System Testing virtual team. At least now in the beginning it consists of each teams' tester and scrum master. Reasoning behind this resourcing is that testers should naturally be interested in their product's overall quality. And unreleasable software is a really big impediment, thus the scrum masters. The concept is actually quite close to Scrum of Scrums. One main benefit is also that the teams will become aware of what the others have been doing.

The virtual team will meet biweekly for a full day of testing. Each day will be like a mini sprint: beginning with a planning session and ending with a review and retrospective. There's still plenty of forming and storming to do, but I have really high hopes for the activity. Already during the first session they were able to catch tens of bugs that would have most probably otherwise stayed under the radar (at least) until the Stabilization period!

Paved with Good Intentions

How Local Optimization May Result in Failure 

Sometimes when you remove a rusty bolt from a system of nuts and bolts and clean it up, it may not fit the original context anymore. In the course of time the rust has become part of the system and should be also taken into account.

In a complex software legacy system this phenomenon may manifest when a certain subsystem is refactored or rewritten. Technically the new part may be superior and fulfill the original specifications, but the changes may still result in nasty regression issues. During the past years the layer of application logic has been built on top of the faulty behavior (the rust).

Same applies in organizational context. High-performance team may outrun the system around it. It may produce results faster than the other parts can consume. This can create queues and waste. Results can be even worse when the sub optimization happens on the unit level. For example when R&D is able to produce results faster than can be delivered or specified.

Usually increasing performance is desirable, but some gotchas should be avoided. If you  want to remedy the possible problems, I’d suggest a system view. Try to improve the overall flow of value through the system. Tweak the parts, but don’t fall for the local optimization. Aim to decrease the lead time and measure things from the customers’ perspective.

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.