Jag gillar berättelser. De förmedlar inte bara kunskap utan även känslan som vi upplevde när vi var där. Detta är inte unikt för mig utan våra fikarum fylls av berättelser där vi delar med oss till varandra av våra upplevelser och de känslor som vi haft. När jag började som konsult för cirka tjugo år sedan så var det flera kollegor som inspirerade mig starkt och jag lärde mig oerhört mycket om konsultlivet genom deras berättelser om kunder och installationer som de varit med om. Vissa berättelser var närmast legender om någon gammal konsulträv som gjort ett hjältedåd när systemet kraschat eller som representerat för sin kund för sexsiffriga belopp, legender som levde kvar långt efter att personen slutat på företaget. Många av dessa berättelser har förstärkts, skarvats och förbättrats med tiden, det är jag övertygad om. Historierna bygger dock på det som de närvarande upplevt och känt även om legenderna idag inte är där för att korrigera upp sanningen. Efter två decennier i branschen så är jag hyfsat säker på att det finns fikarumsberättelser som även involverar mig och projekt som jag deltagit i. De bygger säkert på sanna händelser men jag kan också tänka mig att det finns överdrifter i dem idag. I vilken riktning berättelserna vuxit kommer att bero på den känsla som jag lämnade hos dem som var där med mig så även om jag inte är direkt ansvarig för sagan som händelsen utvecklats till så är jag ansvarig för att ha gett inspiration och anledning till den. Jag kan därför bara hoppas på att jag lämnat folk runt omkring mig med en i huvudsak positiv känsla.

storytelling

Jag har själv en berättelse som jag dragit otaliga gånger vid det här laget i olika fikarumssamtal eller över en öl. Det handlar om hur jag blev oerhört positivt överraskad över Nespressos kundservice. Det hela började med den tråkiga situationen att mjölkskummaren som jag köpt till min hustru ett halvår tidigare och som mest stått och samlat damm visade sig vara trasig när hon en sen söndagskväll kom sig för att faktiskt pröva den. Jag kände frustrationen välla upp inom mig när jag försökte att mentalt gå igenom om jag kunde ha något kvitto kvar och om det eventuellt fanns någon form av garanti på den. Klockan 23 på söndagskvällen så bestämde jag mig för att ringa till Nespressos kundtjänst, mest för att ta reda på deras öppettider då jag förväntade mig en telefonsvarare i andra änden. Döm om min förvåning när en livs levande människa svarar i luren och frågar om mitt ärende. Jag berättar om den trasiga mjölkskummaren och är förberedd på att få höra ett beklagande men istället frågar den trevliga tjejen om jag fortfarande bor kvar på samma adress om när jag köpte den? Jag stammar fram ett jakande svar och hon säger genast att då kan jag sortera den gamla som elektronikskrot så kommer det en ny omgående med posten. Inga frågor, inga ifrågasättanden, bara en attityd som gjorde att jag än idag säljer Nespresso bättre än alla deras dyra reklamfilmer genom min berättelse (som för övrigt säkert putsats lite i Nespressos favör genom åren för att ytterligare föra fram min poäng).

Idag insåg jag att min berättelse kommer att utökas framöver med en motpol (alla bra sagor har ju en hjälte och en skurk).

När jag efter två års missnöje med Viasat äntligen dragit mig igenom deras bindningstid och började se ljuset i mörkret med att kunna teckna ett avtal med en ny leverantör. Två år som kantats av säljaren Viktors direkta lögner och missledningar, oförstående från Viasats kundtjänst i flertal samtal, diskussioner med deras dörrförsäljare som kommer lika säkert som influensan. Idag skulle det äntligen ta slut. När jag suttit i en halvtimmes telefonkö och lyckats bli lite så där lagom less på att detta företag fortsätter att göra mig besviken in i det sista och jag äntligen får tala med en person så upplyser han mig om att jag har bindningstid i ytterligare ett halvår. Jag säger kort att det har jag inte alls och han ursäktar sig i någon minut innan han kommer tillbaka och säger att jag har bindningstid i ytterligare tre månader. Han vidhåller detta och vägrar justera uppsägningsdatumet trots att jag berättar om hur först säljaren underlåtit sig att berätta om den tvååriga bindningstiden och sedan hur kundtjänst i alla våra samtal bara pratat om 24 månaders bindningstid. Nu hade den helt plötsligt blivit 27 månader. Det kan tyckas vara en skitsak i en två år lång historia av dålig kundservice men här brast det för mig. Jag gick direkt in på Viasats Facebook-sida för att meddela dem om vad jag tyckte. Efter ett par minuter dök ett svar upp som andades lite sympati. Kanske skulle de kunna göra lite damage control så här i elfte timmen? Men nej, de kunde ju bara förstå hur jag kände och sedan framföra mina synpunkter till dem det berör. Allting såg ju ut att vara korrekt i systemet och det var bara beklagligt att jag fått fel information under hela denna resa. Där och då bestämde jag mig för att detta blir en del av den historia som jag berättar varje gång ett samtal glider in på kundservice. Den historia som handlade om hur Nespresso levererar en kundservice av världsklass medan Viasat inte klarat av den enklaste skadereglering under två års tid. Jag kommer att dela med mig av denna berättelse otaliga gånger i framtiden långt efter att jag betalat mina hundralappar till Viasat för de ytterligare tre månaderna som de pådyvlade en redan missnöjd kund. Om ni råkar höra mig berätta den historien i framtiden så kommer den säkert att låta lite annorlunda. Nespressos kundtjänstkvinna kommer antagligen att ha kommit lite närmare en helgonförklaring och Viasats horn kommer att ha vuxit sig lite längre. Inte för att de nödvändigtvis blivit värre utan för att att känslan de lämnat mig med och berättelsen som de inspirerat till kommer att bli så mycket tydligare då.

Vi inspirerar alla till varandras berättelser och vi kommer att bli ihågkomna baserat på den känsla vi lämnade efter oss.

“I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.” – Maya Angelou

Advertisements

Most of you have probably heard about sunk cost but being reminded about some core fallacies can be good from time to time. I’m since long well aware of the sunk cost fallacy but as you’ll see I’m still very much fallible.

A new TV series starts airing and I watch the first episode. It turns out to be so-so. Not great, but not a complete waste of time either. So I decide to give it another shot the next week. It doesn’t really get any better but I still have hope for it. The cast indicates that there should be more to it than this, so I keep watching the darn thing for a couple of more weeks. Now, it’s beginning to bother me that I’m still watching the show since it doesn’t give me anything but since I’ve already seen the first five episodes I might as well stick with it to the season finale. Then all of a sudden the network decides to cancel the show prematurely. The bastards!!! How dare they? Hey, I was watching that!

The truth is that the network did what I should have done after the very first episode, they cut their losses and decided for another future. They came to the same conclusion that I (and probably most other viewers) did; that the show was crap. But instead of loosing any more of their precious air time, they decided to cancel the show and try to make money on something else.

Time wasted

Time Wasted

The rational decision for us is to ignore the previous investment and look at what marginal gains we have from choosing an alternate path. Mine would have been to give another TV series a chance or perhaps read a book instead. The time I had wasted on the show was already spent and I won’t get more value from it by wasting more time. The network having spent big bucks on procuring a new show, have to disregard this investment when the audience fail to show up and instead look for something new to fill their schedule with. Which was exactly what they did. Pissing me off was the sound decision, for both of us. So thank you TV network for cancelling the show I was watching, I should have known better.

I think most of us agree today that learning is almost always a bottleneck for our development projects. When asking people after completing a project how long it would take them to do the same thing all over again, the answers usually range between 10-50% of the time it took the first time. The second time around all obstacles involving learning would be removed and everyone could focus on producing. This is where agile methods and practices come in; designed to facilitate fast feedback and fast learning cycles to improve on the lead times.

When it comes to new product development (NPD) most organizations that I’ve come in contact with have a tendency to lose severe amounts of calendar time before the actual development begins. When I started looking into the Fuzzy Front End (FFE – “the phase between first consideration of an opportunity and when it is judged ready to enter the structured development process”) of NPD with a colleague of mine to see if- and how agile ways of working could help during this phase I came to realize that even though learning is what we try to do at this point, the real bottleneck is usually decision-making. Many organizations don’t have a set of business rules to guide them during the decision process for new products and even people on CxO positions are often paralyzed by the Parmenides fallacy; action is more dangerous than inaction.

decision

It doesn’t make sense for us to speed up the other activities of the FFE if the organization is going to waste that time on procrastinating on decision-making. So what can we do to speed things up a notch? It’s been argued that the FFE-part of NPD has an inherent uncertainty and ambiguity to it that makes it an ill fit for structured processes. Be as it may with this (I’m quite certain that we can do innovation and be creative within a framework as well though), the decision process that runs in parallel with the creative processes can definitely be sped up. With a good enough set of decision rules, any company can limit the impact of decision-making as a bottleneck.

When entering the NPD-process, we should frame the research within the limits of our corporate strategy. This will tell us what kind of opportunities to look for. Do we have a plethora of service- and product options to explore or should we stay focused on a given market segment and type of solutions? Are we Google or are we a cab company.

We should decide beforehand on the level of risk that we’re willing to accept. Are we willing to explore completely new products? Are we prepared to explore new technologies? Are we willing to create new markets? Or should we perhaps stick with extended product capabilities?

What level of organizational change are we willing to accept in order to develop and/or produce new products or services? Can we kill an entire production unit and build a new service organization? Or do we have difficulty even to introduce a new role to our organization?

How much are we willing to invest in exploring new opportunities? What payback time do we expect?

Most of us aren’t working for companies like Gore, Google or 3M. We might like to believe that we have the freedom to explore all kind of opportunities but if we snap out of this dream before we act on it, we can become a lot faster at following up on new ideas. What we need at the beginning of our NPD process is to:

  • Make all constraints explicit
  • Decide what data is needed to make a decision
  • Commit to innovation within these constraints

And don’t forget to combine fast decision-making with validated learning and agile practices to minimize the impact of poor choices, because the decisions will not always be perfect. But then again, neither were the decisions that used to slow us down.

The Need to be Needed

January 10, 2014

“A bee is never as busy as it seems; it’s just that it can’t buzz any slower.” – Kin Hubbard

A while back I was coaching a project that was to a large extent staffed by people being experts in narrow fields of expertise that also had other commitments outside of the project preventing them from having any slack time what-so-ever. This constituted quite a big challenge because they all took turns to act as bottlenecks in the process so I decided to run a retrospective focused entirely on how we could free up more of their time in order to improve the flow of work.

The initial reaction I got was almost enough to give up on the idea entirely. Almost everyone started moaning about management and the organization being the problem.
“Tell them to not dump all this work on us.”
“As long as we have to do projects as well as maintenance this will always be a problem.”
“I have to support so many projects that I’ll never be able to set aside any slack time.”

With the support of the project manager though, I decided to run the retrospective despite the chorus of geese shaking off the water. The setup was quite simple; we divided into groups of three and I asked each group to work according to the Iroquois “Rule of Six” to come up with at least six plausible reasons for why key people in the project were constantly overloaded with work. I asked them to specifically look for reasons that were in our reach to act upon. The result was amazing. All groups managed to present at least a handful of reasons showing how we all were responsible of creating this problem.
“I say yes to almost anything.”
“I don’t trust other people to do a good job.”
“I ask other people to help me with stuff without checking if it’s prioritized.”
“I don’t prioritize the work that comes in.”
“I create work that has not been asked for.”
etc.

I was overwhelmed with the candidness and maturity in the answers. This was great; we had found so many things that we would be able to act on in order to ease up on our own as well as our peer’s workloads. With this smörgåsbord of possible actions I didn’t want to do a prioritization to select one or two to implement during the upcoming sprint. Instead I asked if we could take as homework to do a daily act of kindness to ourselves and someone else. Could we at least once a day stop to think if we were about to act according to one of the patterns that we had found and instead take another road?

This is where things started to get interesting again. Amidst the nods and yesses I detected some hesitation as well. The hesitation wasn’t spoken out loud in any way but it was in the air so I asked for a fist of five. Could everyone on the count of three please raise a hand showing their commitment to this homework by showing any number of fingers between one and five?

  • Five fingers being “YES! I’m really committed to this, count on me.”
  • One finger might as well be the middle one; “There’s no way in hell that I’m doing this.”

All people raised four or five fingers except the three persons being the most overburdened, they only held up one or two fingers.

When I asked what made them hesitant about doing this daily act of saying no to another task or not handing unprioritized work over to a fellow project member, they all fell back to the initial reaction of pointing outside their own sphere of control: “It’s not possible to say no.”
“If there’s a production problem it has to be done.”
“We have to do this even if it’s not prioritized.”
“Quality will suffer if we don’t do this.”

I’m not entirely sure if the conclusion I came to after this meeting was correct or not but I suspect that these people thrive on being busy. It could be external factors such as explicit or implicit rewards and/or threats that make people act in ways that puts them in the center of everything but having seen the same people end up in these situations time after time in different positions at different companies make me think that the problem often is self constructed. Some internal belief system or internal reward system make some people act in ways that is hazardous to not only their own health but also the productivity of the team that they work with. I don’t have a turnkey solution for this problem but I would ask everyone to consider this possibility before going about redesigning the organization or taking any other measures on the system.

The problem might not be that we force people to work too much, it could very well be that we allow them to work too much.

Let’s pretend for just a second that we need estimates in order to perform our business. Some of you will say that we do and some will probably say that estimates are a big waste. But for the moment, let’s at least pretend that they have a place.

dice

Usually we do estimation in order to provide some kind of predictability in our deliveries. It’s just that an estimate is not enough on its own. Knowing that something will take 6 man weeks to implement has no value unless we know that we have 6 man weeks at our disposal. We need to combine our estimate with some kind of capacity measure in order to get predictability. There’s a big difference if our team can give the task 6 man weeks worth of attention within the next two week iteration or if they’re overloaded with other work and need 4 calendar months to finish the requested 6 man weeks.

So we need an estimate AND a capacity in order for the estimate to have any value. The thing is that it’s not enough either. When we estimate, we also need to agree on what we’re estimating. We need to have the same view on the expected quality; both external and internal quality. Everyone involved needs to know how the solution is supposed to behave; if the customer expects a Lexus but a developer is about to build a go-cart, the estimate will have no value. Everyone involved needs to have the same view on the level of confidence for the internal quality; if the developer is ok with Windows 95 quality but the tester is expecting a pacemaker level of confidence, the estimate will have no value.

So now we need an estimate AND a capacity AND an understanding of quality in order for the estimate to have any value. The thing is that if we make an estimate and it’s wrong, the effects will fade over time (unless we’re dealing with systematic estimation errors). If a requirement was estimated to take 5 days but actually took 10 days (a 100% estimation error), the effect on a six-month project will be less than 4%. An error in capacity on the other hand will multiply if left to itself. If a team is working in two-week sprints and plans are made with a 10% error in capacity, this error will multiply for each sprint and for a six-month project, we’ll have to add another two sprints to the end in order to finish what we had initially planned. But even worse is the cost of poor quality. These costs tend to rise exponentially with time. The longer time a poor assumption or a bug goes unnoticed, the more code will get built on top of that error and either multiplying the instances of the actual error or at least building dependencies to the error.

In short:
Error in estimate – impact decreasing linearly with time
Error in capacity – impact increasing linearly with time
Error in quality – impact increasing exponentially with time

But where do people put their attention when plans fail? They usually address the estimate and way too often put blame on the teams for not doing good enough estimates. Apart from being unethical since estimates are nothing but guesses, it’s also a waste of time since any deviations from the plan are much more likely to come from errors in capacity measurements (or worse; capacity estimates) or a mismatch in the understanding of what quality (or functionality) was being estimated.

So if predictability is what you’re looking for, don’t invest much in your estimates, instead you should make sure that your capacity is known and that quality (internal as well as external) is well understood. And that’s why your estimates don’t really matter.

About 20+ years ago, I worked one summer pulling cables at a construction site for a newspaper printing company. I was part of a team of about 8 persons and a team leader. For me, this was an internship over the summer, but the other guys were doing this for a living.

The job was quite easy; the team leader looked at the blue prints and told the rest of us what kind of cable to use, where to start and where to stop. Not being too mentally challenged by the task of pulling a cable from A to B, I tried to learn more about other stuff. I asked the team leader how to read the blue prints, I tried to learn more about the equipment being used at the site and so on. Then one day when I came to work, the entire team was sitting in a semi-circle on the floor, smoking and chatting. Our team leader hadn’t shown up since he’d caught one of those nasty summer colds. Not knowing how these things worked, I sat down with the rest of the team waiting for the signal to start working. After about half an hour or so, I realized that nothing was going to happen. We had lost our team leader, so the day would be spent sitting on the floor in a semi-circle smoking and chatting. I figured that this was probably not in the best interest of anyone so I picked up the blue print, looked at what needed to be done and asked the others to join me in pulling a couple of 5 core cables from one end of the building to one of the printing presses. I think I managed to get a couple of guys to help me with a handful of cables before everyone were sitting on the floor again and I realized that this was the way that I was going to spend this summers day.

Part of this experience probably should be used to reflect on my leadership abilities at the time. However, the real learning for me, looking back at it today was that this was a very specialized team without the motivation to self organize. Anyone of the team members could probably have read that blue print, but it wasn’t in their job description to do that and they sure as hell was not going to let a kid still in school tell them what to do either. Today, I see the same pattern in new Scrum teams. They start out as highly specialized member of their teams and if one person gets sick, it’s semi-circle-time again.

But now for something completely different …

Do you remember that scene with the black knight from “Monty Python And The Holy Grail”?

Whether you do or don’t, here it is:

I’d like to see that perseverance and problem solving in every team. “We’re here to solve a task and by God, we will do it … no matter what.”

The team loses a business analyst.

– Tis but a scratch.

The team loses a tester.

– Just a flesh wound.

The team loses it’s ScrumMaster.

– Come ‘ere. We’re invincible.

The team loses it’s back-end developer.

– We’ll bite your legs off!

The self organizing team must be able to heal itself, to lose a leg and still yell “Have at you! Come on then!”.

“Semi-circle” or “Just a flesh wound”?

Tester/developer/ScrumMaster or Team Member?

“Everything we think we know about the world is a model. Every word and every language is a model. All maps and statistics, books and databases, equations and computer programs are models. So are the ways I picture the world in my head – – my mental models. None of these is or ever will be the real world.” – Donella Meadows

I think that the last sentence of the paragraph above is something we all need to acknowledge more. We all hold our mental models so dear that we tend to forget that they are not the real world and that our models are always competing with other models out there, models that may or may not be more useful than our at any given moment.

The problem with us having a preconceived mental model is that we are able to fit everything that we experience into the model we hold most dearly. What we see, hear and sense can, and will, be hammered into the shape of what we already expect.

As an agile coach, I have the benefit of listening to a lot of people and often hearing many different sides of the same issue and it never ceases to amaze me how differently people can interpret the same event.

What is really sad is that as soon as we’ve characterized a person we tend to interpret everything that person does according to our selected stereotype. This reinforces our model of choice and enables us to keep drawing the same [erroneous] conclusions at an ever increasing speed.

I wish we could all learn to challenge our assumptions and our mental models more often and that we could learn to apply a tool like the Iroquois “Rule of Six” in our interactions with other people.

“The Rule of Six [for the right side of the brain] says that: For every perceivable phenomena devise at least six explanations that indeed explain the phenomena. There are probably sixty, but if you devise six, this will sensitize you to the complexity of Universe, the variability of perception. It will prevent you from fixing on the first plausible explanation as The Truth.” – Paula Underwood

If we could do this before judging a person or an event, we would realize how many good people we are surrounded by. It would also make ourselves better persons, more worthy of the benefit of a doubt from those who judge us.

%d bloggers like this: