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.

Values and Principles

Last week I participated in a SAFe SPC 4.0 training. I was already somewhat familiar with the framework after previously attending a Leading SAFe training. After that I have been acting as a Release Train Engineer and heading a System Team for the past couple of years. But never the less, there's always room for learning more and the training was really good. Jennifer Fawcett has an overwhelming amount of experience and she's also really inspiring teacher. Maarit Laanti also shared interesting experiences from her past. I think these 'war stories' are always the most exciting content in any training.

My interpretation of SAFe is a map or definition of a complex system. Or a collection of practices that can be utilized to bring structure to an organization. So I don't consider it as a silver bullet or a project model that should be fitted 100%. And then again, this is just one possible view out of many. Reader is welcome to use SAFe in any suitable way.

But please remember that SAFe and other scaling frameworks are just frameworks. What is really important is the people and interactions that take place within the framework. I find also values and principles to be more important than specific practices.

SAFe Core Values include

• Built-in Quality
• Alignment
• Transparency and
• Program Execution

If you find for example transparency to be sore topic in your organization, then SAFe won't help you out much. In the end you might come to a conclusion that 'SAFe is broken', although the organizational dysfunction has just been uncovered by the transparency. I think the same has been pointed out about Scrum.

Then the SAFe House of Lean contains the following pillars:

• Respect for People and Culture
• Flow
• Innovation
• Relentless Improvement

As we are all unique, we have different biases. I for one emphasise the first and last pillar most. For me one of the most important things is that people respect each other. This regardless of gender, race or title. Constructive disagreement is ok. It even drives innovation. But respect and trust should be in place. Then you can take a humble look in the mirror and start the relentless improvement.

I'm not going to repeat points of Agile Manifesto here, but I'd like to point out a bit less known framework. Trust, inspirational motivation, intellectual stimulation and individual consideration are the corner stones of deep leadership. It was taught in Finnish army's leadership training and it made a lasting mark on me.

Sometimes we get lost in silos. It is easy to mentally divide people to 'us' and 'them'. Seeing the other person as a human being with hopes and dreams may help to respect the other person. And remember, even though you think something someone else is doing makes no sense, it probably makes perfect sense to him or her. Our past environments and experiences have molded us and we all see world a bit differently.

My own management/leadership methodology is based on making things easier for others. Instead of sub-optimizing things for yourself, try to make things better for others. Do not make others wait. And increase transparency as much as you can. When everyone works according to this very simple rule, the combined results can be huge.

Importance of Environment in an Agile Transformation

I attended today a SAFe 4.0 event arranged by a Finnish training company called Nitor Delta. As a guest speaker they Michael Stump from the Scaled Agile Inc. The event was also a good meeting place for SAFe practitioners. I must say that I saw quite a few familiar faces. And met many new people who I can hopefully later exchange experiences with.

After writing a case study, my company has drawn a lot of attention from other (potential) SAFe adopters. I have a bit mixed feelings about it. Of course I'm happy and proud about the attention, but being a Finn, it's difficult to handle the situation. And then again, since I see all the daily difficulties we deal with, I sometimes feel tempted to say "..but we still face these difficulties". But maybe there's no need. I guess everyone understands that things are in reality much more complex than in theory.

From http://finnishnightmares.blogspot.fi

But from the conversations that I participated after Michael had finished his presentation I learned that environment matters a great deal in SAFe/Agile adoptions and transformations. First I was somewhat against the idea of training everyone at the beginning of the adoption process, but maybe my first impression fails me there. In some cases I think even training is not enough, but some people should get their brains totally rewired. I mean, if you have done something in the same way for decades (or even years), it could be overwhelming to modify your daily routines.

If I think about possible factors why the transformation was successful in our case, I could easily list at least a few. There was a big management support. Previous and current heads of R&D were supportive for the idea and also the Chief Quality Officer. I think also the CEO saw potential in the new practices.

We had already been trained in Scrum when the big organizational change was initiated. All developers had received training in Scrum essentials and every Scrum Master and Product Owner was certified. Scrum Master and tester Communities of Practice were also formed right at the start. So good practices had distribution channels.

Release Process was established even though at first we didn't plan the releases. But the decision to shorten the release cycle was made. Release Manager, a person who would facilitate the release planning and execution was also appointed right away.

Then I think a big deal of the change can be credited to a couple of champions. People who were in key roles (RTE, Owner of Software Development Process, Chief Portfolio Officer, line management of R&D) made big contributions. Having a vision of how things could be done was important, but just as important was the support from these champions. And finally the support and engagement of employees. Everyone wasn't eager to embrace the change at first, but enough many were.

During the conversations with other companies I have realized that there are other, more subtle things that supported the transformation. Some that I had never even thought of since they are rooted so deep in the culture and operations. The organization is not flat, but there are exceptionally good possibilities to access information, suggest new ideas and to participate in the decision making. Also the developers are treated as experts. And there's one company value that I hold in the highest respect: Enjoy Working Together.

In the development money is not an issue. I mean, there's no unlimited budget, but people in development get to fully concentrate on the contents. If something is considered worth doing and there's clear potential, it will be done. There's no sharing of the blanket between different business units. (I have never needed to worry about CapEx or OpEx.)

As a conclusion, I think there were quite a few things that made the transformation possible. Some are such that people living inside the system do not even perceive. In a way I'd be tempted to say they don't realize how lucky they are. So let me conclude my post with a few pictures.

Office Breakfast

Foosball table

Hackathon trophy

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.

Slack & Blink

I read Tom DeMarco's Slack and it made me question my own role as a process owner. The whole book seems to be somewhat manifesto against the sort of 'efficiency' that targets keeping everyone busy and also for management by objectives. The second one has been criticized ever since W. Edgar Deming, who I most relate with systems thinking.

In the end, Slack isn't against efficiency. At least that's my interpretation. It tries to make a separation between making individual parts (seem) efficient (busy) versus making the overall system efficient. I guess the lean approach would anyway consist of having enough slack to keep the flow smooth.

Another topic Slack points out is the culture of fear and how it can effectively prevent organizational learning. In a culture of fear organization you can not take time to learn new things. You always need to be efficient and busy. Inevitably this will keep people in their comfort zones because taking the time to try new things is just too risky. To transform such organization into a learning one you would first need to make people feel safe, cut off internal competition (between units or other silos) and give people enough slack for deliberate slower-than-expert training.

Slack got me thinking about process development. Just to keep in mind that busyness and effective value delivery are two very separate things. I sure hope it stays clear to me. Reminder from time to time doesn't hurt.


After Slack I started reading Malcolm Gladwell's Blink - The Power of Thinking without Thinking. It concentrates on our first impressions and thinking that we do unconsciously. I think it's very much related to Thinking Fast and Slow by Daniel Kahneman. (Now I realize that Gladwell wrote Blink six years before the other book. I just read them in reverse chronological order.) I analyzed Kahneman's book in my previous blog posts (here, here and here). Blink also supports the idea that we operate a big part of our day on an autopilot. Many of our choices are just too import to be left for our overanalyzing conscieousness. Instead they are made more efficiently, unconsciously.

Interestingly, we cannot tell how we end up with our unconscious choices. They happen 'behind closed door'. There are many studies that indicate that we don't have a clue. We can say we like this brand more than that, but usually the reasons are not known to us. And the setup of the experiment also matters. In short sipping test Pepsi usually wins Coke. But when you drink a whole bottle at home, you might change your selection. Or artist that you don't necessarily like after hearing a short sample might still be a huge success live.

Both books have been really enjoyable and worth reading. I can easily recommend both of them.

Developing Metrics for Development

Last month I wrote about my intention to try Cycle Time as a metric for software development. Back then it was still hypothetical, now it's real. Maybe it's still a bit early to draw any final conclusions, but it's already evident that I failed miserably in communicating the reasoning behind the change. And the criticism is well deserved.

I selected the average Cycle Time during past month as the metric for each team. In a way it is a good metric and gives indication about how quickly the value was realized after the work on a backlog item was started. But all backlog items aren't equal and also work type and intensity differ during the release cycle. In the beginning of the release cycle teams mostly work on the new development. Nearing the end the period emphasis is shifted more towards testing and bug fixing. Issue life cycle tends to be much shorter with bugs than when creating new functionality.

It is also questionable if one monthly average number can help in decision making, in essence serve as an actionable metric. You can see the trends in longer time intervals, not much more than that. Another angle is that a team can be really mature and produce outstanding results even though they don't split their Stories into very small parts. Their average deviation can be small and thus predictability high.

Then again I feel that the metric got a little unfair criticism when it was compared with Lead Time. In the end the company is interested in how the customers experience our products and services (Customer Experience = CX). But this includes many topics that are out of scope for software development. Like the company brand(s), how salesmen conduct their business and how the customers are served by the customer service. I think the software development part of the system (company) can greatly affect the User Experience (UX).

 

I would love to get the big picture correct. So personally I feel that the CX is more important than UX alone and Lead Time more important than Cycle Time. But in both cases the internal part is relevant component of the whole and deserves a metric of it's own. (It would be so cool if I could somehow bundle measuring UX and Cycle Time somehow... Probably there's no such easy connection. I think relationship between Lead Time and Customer Experience is much easier to show.)

Now the current bleeding edge is to try using the whole information provided by the JIRA Control Chart instead of simply one number. I haven't yet figured any cons, but on the pro side you get trend lines of where the performance is developing and standard deviations. Of course you can still identify the release cycle from this data, but you can draw other conclusions too. Increases in rolling average or standard deviation can signal trouble. And when the figures are followed regularly, the team can be aided in a timely fashion.

 

Currently I feel like I'm making too rushed decisions. I'd like to involve other people more and ask for their input already before I make an experiment. Now I mostly just measure the impact and make amendments, but I'd like to concentrate on this more. Let's see if the Santa Claus and New Year will bring a difference. In case this will be my last blog post this year, I already wish you all Merry Christmas and Happy New Year!