I have previously been a process owner. I've improved existing processes via different tools and techniques. Audited practices and interviewed actors, even chopped down the activities to a value stream map. But never before (that I can recall) have I been involved in the definition of a process.
In this case the actual process exists (people do actions in a certain order and with a desired outcome in mind), but it isn't documented. There are neither no metrics defined to see if the process is working fine or not.
To be honest, there is documentation. The problem is that there is too much documentation and it's scattered around different places in the intranet. So, in this case I'd be willing to abandon the old documents, try to extract the current process through interviews and workshops and write it down as simply as possible. Fortunately there are very nice tools available in the parent company that can be utilized.
Some general tips to avoid pitfalls (that seem rather common):
Keep things simple. Don't go too much into details.
Integrity. You don't want to have 18 different ways to describe a process flow.
Visulization is power. Figures clarify the message.
Somebody should have ownership of the documentation. That will help keep it alive.
The list isn't exhaustive. But it will get you started.
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.
In the series of daily life inspired posts, I return to one of my favorite subjects: cookery. This time I was making some vegetable casserole. I needed to peel and shred some carrots and I fell into the age old trap: big batch size.
As you can see, I had in advance decided to use more than six carrots. While I was peeling them, I was aware that I should have peeled end shredded them one by one, in a one piece flow. But against my own good, I peeled and cut the heads off from six in a row. I was convincing myself that it was more efficient (although I was creating extra inventory).
After peeling the six carrots I finally started to shred them. Only to find out that by cutting the head off I had made the work more cumbersome. And now the fault was multiplied six times. If I'd done a proof of concept (gotten one carrot through the whole pipeline), I would have only had one faulty carrot. Fail fast!
I faced another problem later. I would have been well off with only three or four carrots. But since I had already peeled six, there was no turning back. Now my costs were bigger than they needed to be, I could have saved some veggies for the next time.
The same phenomenon is easily found in software development if you use kanban board without proper WIP (work in progress/process) limits. It's easy to pile up too much work that is waiting for testing or merging to the main branch. The flow is far from optimal, but perceiving the problem is far more difficult due to the fact that the material is less tangible, in most cases information.
The final result was quite edible despite the faulty process. :)
In Finland we have a rather nice concept called freedom to roam (jokamiehenoikeudet). It grants a big bunch of different rights that you can utilize while wandering in the nature. For example you can camp or pick berries or mushrooms (excluding backyards, gardens etc.) My next story is just about that: picking blueberries.
There are two main ways to pick the berries: by hand or with a berry-picking rake. Picking with a rake is by far faster than handpicking. But there are other aspects to consider. Blueberries are soft. The rake will break at least some of the berries. Also, they will be accompanied with a lot of extra leaves and other rubbish. That's why the method will require you to clean the berries.
From lean & quality point of view there are a few problems. First, you will need to have extra storage space. You need to keep the clean and dirty berries in different containers. And the batch size is really big. All the dirty and clean berries need their own space. Second, you will need to move the berries. In lean methodology this is considered waste. In reality, all the extra touching will also make the berries sticky from their own juice.
With handpicking you can pick straight to the final container. You don't need any extra space and there's no extra movement. This also means that the berries will stay in better shape. As a downside, your hands will get blue.
But as in any other things, you should think about your priorities. Largely it's quality versus time. If you are not in a hurry, I'd suggest handpicking. You will achieve a one piece flow. From the forest ground straight to a freezer ready form. But if you are trespassing on someone's backyard and want to get away fast, just use the rake a flee before someone will shoot you. You can then live to clean the berries at home. ;)
One should also note that this isn't as black and white with other berries. For example cowberries do not get as sticky even when you use a rake. And most of the time you don't get as many rubbish either. So there the quality is almost the same with both methods, rake is superior in speed.
Lean thinking is an interesting (and many times rewarding) thought experiment and can be applied also in ordinary life.
This post will be even longer than what I usually write, almost like a short novel. (Disclaimer: it might take longer than one toilet break to finish. ;)) It will be a story of extremely talented colleagues, supportive supervisors, growing organization and a journey of one physicist. Acknowledging the risk of sounding like self centered dick, it will be a story about me and my professional career at Napa Ltd.
Prologue
I didn't struggle much at school. I learned things quite fast without the need to repeat. Especially mathematics was interesting and I got good grades. Later in high school I selected extended levels in mathematics, physics and chemistry.
When it was time to select the place for my studies, selection criteria was to pick the most difficult one. I went to study Technical Physics and Mathematics at the Helsinki University of Technology. My major was Physics and minor Computational Science. This was the first time I really needed to study hard. The challenge felt good. I mainly selected courses based on their difficulty rather than on their usefulness: quantum mechanics, functional analysis, etc. I frowned upon economics and applied mathematics (the topics that could actually be useful in business world!) I did study a bit programming and one course of differential geometry that would come handy later. During the summers I made two special assignments about positron annihilation measurements, one practical and one computational.
Early Years
In 2007, when I had completed almost all my studies, I started to look for a thesis researcher position. Coincidentally, there was a Talent-IT fair at the campus. I wandered around and found the stand of Napa company. I had never heard of it, but they seemed to do things I could maybe contribute in and they had a master's thesis position open. Worth mentioning is that I had experience only in two programming languages: Java and FORTRAN. Insidentally they were also present in Napa's stack at the time. :)
Tom Sundell, who I had met at the fair, contacted me later and we agreed that I would come for an interview. There were two alternative topics: some kind of pattern library or a study about the hull surface representation methods. The second one was closer to what I had studied. While writing the thesis I got familiar with NURBS surfaces, Coons patches, T-Splines and learned a lot more about the NAPA program.
After completing my studies I joined the NAPA Technology Unit as a Systems Analyst. Mainly that was a fancy name for a programmer. Back then there was a clear separation between core developers and GUI developers and I was proud to work with the core challenges.
All developers were part of a big pool from where they were assigned to different projects. Releases were planned for one year at a time. I don't really know how that was done, I had zero visibility (and interest at that time) to the topic. Business people came with specifications and programmers wrote code. Everyone was an individual contributor and a specialist. My field was geometry. Some of the things I'm proud of from that time include upgrading the finite-element 2D mesher, implementing an envelope surface for a given set of planes, participating in renewal of surface modeling and implementing free-form deformation into the program.
Work was in a way easy for a developer, since all you needed to worry about was the implementation. But with multiple overlapping projects, the resource allocation became challenging. Some key contributors were needed in almost every project. I remember that my closest colleague, the more senior geometry expert, was simultaniously in 5-6 projects! At that point it was clear that some kind of change was needed and the organization was ripe for it. Sense of urgency was there.
Adopting Scrum
We had already made some experiments on using a scrumbut for some of the projects. In the early 2012 the company had made a decision to make a radical organizational change, start working in teams and define a process oriented way of working. Teams were formed around products or feature regions. My team was called Model team and we worked with modelling related topics. Teams elected their own Scrum Masters. I was really interested and got elected. And so our distributed team (people in Finland and India) started learning Scrum.
We also formed Communities of Practice. One gathered together the Scrum Masters and it was facilitated by our Chief Scrum Master. But then this person was assigned to another, more urgent role and the position was left open. There was an internal job ad for the position of Software Development Director. I applied.
I didn't have enough experience to fill this role, but I maybe had some potential. In the end the role was split. Our Chief Quality Officer took the ownership of Software Development process, but I acted as his right hand man and owner of the Scrum framework. I became the Chief Scrum Master. Maybe I could describe our work in a following way: we discussed things together, he wrote specifications and followed metrics and I interacted with the teams. I think it was fun and we had a weekly meeting where we discussed the Agile topics on a sofa. My workplace was in an open space with lots of whiteboards and I called it the Agile Center of Excellence. :)
During this time I went to a couple of really useful trainings. Agile Coaching and Leadership was about what the name implies and then Leading SAFe course. Both were really influential and had a big impact on my work life. At that time I also started to facilitate retrospectives for the whole company.
Entering Management
One day in the late 2013 my boss invited me to a meeting together with the Chief Quality Officer. There were going to be some changes to the organization and I was given an opportunity to take a lot more responsibility. My boss used to be also the supervisor for our Release Team that guards the quality of main codeline, provides and maintains tools and other stuff. He was also the owner of our Release Process. He moved to another role and I adopted all that. I became the owner of the whole Software Product Creation value chain. This meant pretty much all actions that take place in development before the software is given to customers. In addition it meant that I would be a Product Owner and supervisor for the Release Team. At that time I decided that what ever problem someone had with our technology function, processes or results, I would take the responsibility. No bouncing the problems around and asking the person to find someone else. I would take full responsibility and later then find out who could help me fix things.
My boss had been sitting in his own room, but I wanted to sit together with my team. (The room was next to the team room and was still available for private discussions and calls.) At the time there were three members in Finland and two in Romania. The guys were brutally skilled. I really understood that in an expert organization being a supervisor is mostly about removing obstacles and making sure your team can work effectively. The best implementation decisions always come from them. My role was to set priorities and make decisions when needed. Now afterwards, the time when I worked together with my team was the high peak of my working life so far.
As the Release Process owner I also wanted to plan the releases differently. I had been very unsatisfied with the level of transparency on the plans. As I wrote earlier, previously developers had no idea how the releases were planned. Specifications were just dropped on their laps. I decided that we should make things more public. In 2014 we arranged our first Release Planning Day and I have described it in more detail in this previous post. I think I can take some credit for kick-starting the practice, but most of it goes to the organization. People, especially Product Owners and Product Managers, came in prepared and played their role well. I remember one colleague saying something like "Thank you. Now for the first time I get an overall picture of what's happening in this company."
Due to some organizational changes and other events, my team size was diminished until at one point we only had me and two release engineers. We started a recruitment campaign and this was the first time I ever recruited anyone. We got one new team member into Finland and into India. Then for the first time we had a Release Team member in all our development offices.
Side jobs and other activities
Before the management I was also an Industrial Safety Delegate for a few years. I was also the first Shop Steward. Both of these side jobs originate from my urge to keep the game fair. As a mathematician I like defined rules and it would be awesome if the world followed such rules. Unfortunately I have also learned that it doesn't really happen in practice. That's why it's better to stay agile, adapt to different situations and update plans accordingly.
One nice side job was also acting as the internal facilitator for strategy renewal work. It was a real vantage point over all functions in the company. And really, really interesting.
I also worked as an internal auditor. Napa has an ISO 9001 certified management framework and holding internal audits is part of the model. Again, a really good chance to learn more about different parts of the company and how they interact.
While being responsible for so many different things simultaneously I started to drop balls. Or maybe not totally drop, but I felt that I cannot do the things as well as I wanted and as well as they deserve to be done. I really liked being the Chief Scrum Master and manager for the Release Team, but those were responsibilities that could be easily transferred to others. So I did. Reluctantly, but from my own initiative. I felt that the organization would get the biggest bang for a buck when I would concentrate on the value chain and activities that go across the function boundaries.
At this point I also became the secretary for the Portfolio Management Team. I had been driving the adoption of Scaled Agile Framework (and become a certified SAFe Program Consultant) and felt like the owner of the framework. I wanted to bring more structure to the way things were decided on the top level. Unfortunately the process for introducing new Epics was largely unknown to organization in general. I helped to transform the Roadmaps from purely technology and development focused into something that better takes into account also other activities like service development and marketing. The experiment is still ongoing.
During this time I had come to a decision. I want to see how things are done in other companies. To see in practice if I could make an impact and to help other companies too. And that is why my journey will continue from now on somewhere else.
Epilogue
Napa has been an extremely good place for me to grow. During the past nine years the company has gone through a big transformation. From individual responsibilities to team responsibilities, growing organically both in number of employees and in revenue. I feel I've grown with the company. I have faced challenges and opportunities. I'm grateful to all my colleagues, my supervisors, everyone who have supported me.
I hope my departure will also be a chance for Napa to do things differently. I'm sure they will continue finding new and better ways of working. Especially the new products and the investment in improving user and customer experiences sound really promising.
I will miss this place dearly and it will always have a special place in my heart. And who knows, maybe I'll one day return. Hopefully I haven't burnt any bridges behind me. Godspeed Napa! And enjoy working together!
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. )
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
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!
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.
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.
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.
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.
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.
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.
