The Stories We Inspire

I’m a fan of story telling. Stories not only transmit knowledge but also that feeling we had when we learned something. This is not just me, our break rooms are filled with stories in which we share our experiences and feelings with each other.

When I first started as a consultant about 20 years ago, I was strongly inspired and influenced by several of my older colleagues and I learned a lot about life as a consultant from their stories about clients and installations that they had worked with. Some of the stories almost became legends about the heroics of some veteran consultant saving the day when the system crashed or who spent an obscene amount of money on a dinner with a client. Legends that lived long after the person had left the company. I’m sure that many of these stories had been improved, patched and polished over time. Even if the legends themselves weren’t there to correct the improved truths, the tales were based on the feelings that the people who were present had experienced. After almost two decades in the business I’m pretty sure there are break room stories that involve me and the projects that I’ve been a part of. They’re probably based on true events but I can imagine that they also contain some exaggerations and half truths today. The direction that the stories have taken will depend on the feeling that I left with the people who were there and even if I’m not directly responsible for the tale, I am responsible for giving inspiration and reason for it. I can only hope that I’ve left most people around me with a positive feeling.

I have a story of my own that I’ve told so many times by now over a cup of coffee or a beer. It’s a story about me being pleasantly surprised by the customer service at Nespresso. It all started with the not so pleasant realization when we learned that the milk frother that I had bought for my wife six months earlier and that had been collecting dust ever since was broken when she decided to use it one late Sunday evening. Frustration was building up inside me while I was mentally working through if there would be a receipt somewhere and if we had some kind of a warranty. At 11PM Sunday evening I decided to give the Nespresso customer service a call, mostly to find out their opening hours since I was convinced that I would be met by an answering machine. Oh, the surprise when a human being answered and asked me about my reason for calling. I explained the deal with the broken milk frother and began to prepare myself for a “sorry sir but there’s nothing we can do without a receipt”. But instead the girl on the other end just asked me if the adress I had provide at the time of the purchase was still valid? I managed to stutter an affirmative answer to the question and she immediately told me to sort the old one as electronic scrap and expect a new one being delivered to my home within a couple of days. No questions and no questioning, just an attitude that to this day keeps me selling Nespresso better through my storytelling than any of their expensive commercials. My story might have been polished a bit over the years though to make my point even more explicit.

Today I realised that I will expand my story from now on with a counter story since all good tales come with both a hero and a villain.

When I after two miserable years with Viasat as my cable and broadband provider finally had come to an end of their 24 month contract period and was beginning to see the light where I could sign with a new provider. Two years lined with lies and misleads from Victor the sales person, countless calls to an unsympathetic “customer service” and long discussions with their door-to-door salespeople that would pop up as regularly as the flu. Today was the day when it would finally end. After waiting on the phone for half an hour I was quite fed up with being disappointed by this company to the bitter end. When I finally got to speak with a person he tells me that I have six more months on my contract. I just gave him a short no, I do not have another six months on my contract. He excuses himself for a minute and then comes back to tell me that I have another three months left on my contract. Despite me telling him about how Victor the salesman had completely forgotten to tell me about any contract period at all and how all my discussions with “customer service” since then had been about a 24 month contract he still insisted on holding me to a 27 month contract. These additional 3 months might seem like a petty thing in this two year long disappointing journey but I had just had enough. I went to the Viasat Facebook page and gave them a piece of my mind. After just a couple of minutes I got a reply with a small hint of sympathy. Could this be some last minute damage control? Could it be that they had finally come to their senses? But no, they could of course sympathize with my feelings and regret the poor communication but everything seemed to be ok in the system.

That’s when I decided to make this story a part of the story I tell every time a discussion enters the topic of customer service. The story about how Nespresso delivers a first class customer service experience while Viasat can’t do even the slightest damage control in two years. I will share this story countless more times in the future, long after I’ve paid for these petty three months that they forced on an already disgruntled customer.

If you hear me tell this story sometime in the future, it might sound a bit different. The girl at Nespresso will probably have come a bit closer to canonization and the horns on Viasat will have grown a bit longer. Not because they necessarily have become any worse but because the feeling they left me with and the story they inspired will become more crisp by it.

We all inspire each others stories and we will all be remembered by the feelings we left behind.

“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

Berättelserna vi inspirerar till

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.

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

Trust Is A Must

We all know that Agile is as buzzword-ridden as anything else that helps people generate an income. There are a lot of gems among the buzzwords associated with agile ways of working though but a lot of the time we tend to take them at face value and not look at where and how they fit in. I’ve been looking at some agile practices and tried to reason around the relationships between them and one of the things I realized was how essential Trust is in order for most of the other practices to work. You can fake a lot of things but if Trust is not truly there so many of the other things we try to do will not only fail, they might also make things worse.

One practice that has always been at the essence of agile is Transparency; we want everyone involved to have current and correct information. Adding a window to a solid brick wall won’t offer any Transparency though. We can’t buy Transparency in the form of a whiteboard. Worst case scenario, the whiteboard only serves as giving credibility to lies, useless data and wishful thinking. Transparency needs to be combined with, among other things, Trust and Autonomy to provide value. The “Transparency” offered when Trust is lacking will never be true Transparency. It will be a display of what the team believes that people around them want to see. It will be fidgeted numbers such as story point inflation, velocity boosting with “almost-done” stories and smokescreens hiding work performed under the radar. In short, any “Transparency” offered when we don’t have Trust or we suspect that we’re not Trusted will be a pile of lies.

So if we add Trust, will that transform Transparency to a valuable practice? I’d say no. Not unless we also add Autonomy to the equation. A team that is not Autonomous will always have dependencies to people and teams outside the own team in order to deliver any business value. When all a team can deliver are small parts without intrinsic value, the data that come out is mostly worthless. No true progress can be shown, only task completion. In any cases but the truly basic ones, task completion won’t give us much information regarding how close we are to realizing any true value. The complexity of what we do will hide a plethora of new challenges behind every completed task. Challenges that only surface towards what we thought would be the end, when we put everything together. In a similar way if we have an Autonomous team that lack Trust and/or Transparency, they are potentially a true danger to the organization. If they act without Trust, it will be a high stakes lottery ticket where there might be a brilliant idea in the jackpot but more likely the team will be a liability that acts without any information sharing with the rest of the company. Adding Trust could be a way to better the odds of something good coming out but without Transparency it will not be aligned with the rest of the company and its strategies.

Before adopting the next good practice, see where it fits in your context. Look for the untold prerequisites for the practice and consider if you fulfill them. Do you have the necessary mutual trust in your organization? And remember that trust ISN’T earned; it has to be offered in advance because people WILL act according to the expectations that are offered to them.

Bastards … thanks for cancelling my show!

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

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.

Accelerating the Fuzzy Front End

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.

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.

What Containers Are You Up Against?

Have you ever experienced working in- or with “teams” that never seem to get to a state of working together as a team? I put the word teams within quotation marks since these aren’t really teams, they’re just administrative units. This has happened to me a couple of times and no matter how much we struggled with trying to get everyone on the same page through working with visualization, teambuilding, meeting formats, goal setting, work spaces etc, everyone would go back to their desks and continue to work as fractions. I’ve gone through several phases of explanations and rationalizations in my attempts to explain to myself why we had these problems. A while back Esther Derby introduced me to Glenda Eoyang’s work describing the effects of containers on systems and that really put the spotlight on some of the driving forces behind our problems.

Basically a container is something that bounds one part of the system from another and constitutes a difference. Containers can be:

• something physical such as walls, desks or cubicles that separate people or unite people.
• of organizational nature; people reporting to different managers, belonging to different departments or being hired consultants as opposed to employees.
• something conceptual such as purpose or rules.
• behavioural, e.g culture or family situation.

The effects of these containers will greatly affect how people are going to work together. Some of them will work in favour of collaboration while others will drive a wedge between people. When I began to model the containers that I could identify within the troubled teams it was really easy to see how many things were pulling people apart instead of holding them together.

People may have been assigned to the “team” and in best case even be co-located. We might have a unifying goal of delivering a product or service but that’s where the positive forces ended. Then people would be experts belonging to different organizational units. They would be reporting to different managers. They could get input to their work from different sources. They would be seated together with a few people with the same kind of expertise. They belonged to different budgets. Their personal goals were set with different managers and not aligned. They belonged to different subteams. They would have to work on other projects outside of the dedicated “team”. Etc. Etc. Etc.

Seeing all these forces working against us made it clear that we had a snowball’s chance in hell of building teams that would actually work as teams. For every action we took to align the team members there would be ten other actions around us that pulled us apart. My guess is that if we would have come much further if we would have focused more of our energy on identifying and redesigning the root causes of the forces pulling people away from each other instead of performing a tug of war with these forces.

Some time ago I was asked to work with a “team” that “had problems delivering” and “the few things that did come out of the team was of poor quality” and as if that wasn’t enough, “people were generally not happy about working in the team”.

The “team” – it turned out, consisted of a handful of developers. They got their work from a couple of different business analysts in different parts of the organization and when they were done coding, assigned the work to some testers in another part of the organization. Before taking on the assignment I made one request and that was to get to work with all three disciplines as one team; requirements, development and test. We did a lot of different things together in order to overcome the challenges but the one thing that made it at all possible for us to create a high performing team was the tearing down of old containers and building a new one around the team.

I’m sad to say that the reason I’m so certain about the power of the containers in this case was that as it turned out, the company structure wouldn’t allow for this organization in the long run. Soon after I left the team, group managers once again split the team into three parts; requirements, development and test, each group with their own team lead. None of the other practices we had put in place were strong enough to withstand this break-up and pretty soon everything was back to square one again.

My lesson from working with this team was that it’s not enough to learn to see these invisible structures, we also need to see the incentive systems that put them in place. But I’ll save that for a later post.

Scrum of Scrums – A Communication Thermometer

I’ve noticed that a lot of organizations seem to have problems with Scrum of Scrums. Some coaches refrain from recommending them altogether while others might use them with low expectations. Without making too many generalizations I’d like to describe one of my more positive experiences using Scrum of Scrums – as an indicator of our ability to work together.

My assignment was to coach a Scrum project with ~100 members and seven development teams distributed over three countries. One of the pains that were brought to my attention early on was how dysfunctional the Scrum of Scrums was. All the ScrumMasters and the project manager would have a teleconference three times a week where the ScrumMasters would take turns giving status reports(!) and complaining about the problems they had. I was approached by some of the ScrumMasters asking me if we shouldn’t have the meeting less frequently since “nothing new is being said. The same problems are being brought up in every meeting.”. I asked them if they thought the real problem was the frequency of the meetings or their inability to solve problems between the meetings. They kind of recognized my point and agreed to continue with the three weekly meetings for a while longer.

Meeting

We began to move away from giving status reports and I also suggested that they started to write down the issues that were being brought up and make sure that unless someone claimed responsibility for actually working on an issue, they wouldn’t be allowed to keep complaining about it in this forum. My idea of writing down the issue was to create an excel-sheet or something similar in a shared folder but apparently in this organization, there would have to be a JIRA project to store such information. It also turned out that it would take about a month to create said JIRA project.

Since I had a hard time seeing that JIRA would be the way this problem got resolved, I also started working on other things in parallel. The first thing we did was to get all the ScrumMasters together to get to know each other. I managed to get the funding to fly all ScrumMasters to one of our sites and hold a retrospective and some other workshops. It was a great day with people getting to know each other but it still wouldn’t be enough. When, towards the end of that day, I asked if everyone in the room had everyone else on speed dial, the frightening answer was that no-one had anyone else’s phone number in their cells. Getting this problem solved was easy, the problem was to get everyone to use the phone numbers.

After this day together, I began requesting from each ScrumMaster to call all the others’ on a daily basis. Whether they had an issue to talk about or not, they should at least make a social call to see how the others’ were doing. This didn’t happen immediately; most thought that they’d get away without making the calls but I kept asking them about it in our one-on-one’s.

I can’t tell exactly when the transformation happened, but before the new JIRA project had been set up, I noticed that fewer and fewer issues were being brought up during the Scrum of Scrums. Instead people were having social discussions and talking about problems in a past tense. When I started inquiring about this I learned that there were still a great deal of issues but now they were being solved outside of the Scrum of Scrums. The teams (or at least their ScrumMasters) had begun caring about each other. One team even offered to send some of their developers to another country to help one of the teams there before the other team had worked up the courage to ask for external help.

In a little more than a month we went from having a meeting that didn’t help us coordinate any issues or solve any problems at all, to holding a meeting where there were no issues to coordinate and no problems to solve. This made me realize that the daily stand-up and the Scrum of Scrums might not really be any solutions in themselves, but rather indicators of how well we communicate within our teams – outside of the meetings.

The Need to be Needed

“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.

Looking back – upside down

I love retrospectives and I love experimenting with different formats for my retrospectives. Today I tried a couple of new things that worked quite well so I thought I’d share this format with anyone interested.

The background is that I’ve just started coaching a somewhat new team that’s been going through a lot of changes lately. They had no history of doing retrospectives together so we had to start from scratch.

I almost always base my retrospectives on the setup described by Esther Derby and Diana Larsen in their excellent book:

1. Set the stage
2. Gather data
3. Generate insights
4. Decide what to do
5. Close the retrospective

Normally I add the step “Follow up the last retrospective” between steps 1 and 2 as well but this time there was no retrospective to follow up on so I skipped that one. Instead I added another item; “Set a challenge”. I’ll get back to that though.

Set the stage

I explained why we do retrospectives and went through the agenda. Then we took a look at Norm Kerth’s Retrospective Prime Directive and I made sure that everyone was committed to follow it. Finally we did a check in. Today’s check in was to answer the question: “If I was a weather, what weather would I be right now?”

• “I’m sunny.”
• “I’m sunny with some wind, because I’ve had some trouble with my computer today.”
• “I’m a big dark cloud.”
• etc

Since we had one big dark cloud in the group, I asked everyone who had something on their mind that bothered them to write this down on a piece of paper and put it away in a pocket until after the retro. This is a symbolic action but it often helps people to mentally put their problems away for a while.

Set a challenge

I had never tried this before but as a way of focusing the retrospective I wanted to try and turn it inside-out or upside-down and start with what we wanted to achieve. I asked the participants to work in groups of two and come up with a challenge for the team in three different dimensions:

• Well-being of the team members
• Productivity
• Quality

The reason for having these three dimensions was to find a balance between things that could possibly be compromised if only one or two of the dimensions were considered. I asked them for small and concrete challenges that could be tried within one month. No high goals that the team would have to live by for their rest of their lives, just simple, measurable challenges to experiment with.

The groups came up with a lot of great suggestions in all three dimensions. Several groups had come up with duplicates but I thought all ideas were really good. Now we needed to narrow the field and select just one challenge in each dimension.

The vote

I’ve been using dot voting a lot in the past but for a while now I’ve had a nagging feeling that it doesn’t produce great outcomes. Small issues that are only important to a minority can easily be selected before more important issues that would benefit a larger group depending on people’s tactics. I decided to try a (for me at least) new way of voting that I came up with. I based the idea on the concept “fist of five” and decided to call it commitment voting. I asked everyone to put a vote on all alternatives. They should give each alternative a vote between 1 and 3.

1 was a disqualifier or veto. “I’m actively taking a stand against this.” If anyone put a 1 on an alternative it would mean that the group wasn’t committed to that alternative and it was taken off the board. (This is probably a sign that we need to talk more about this as well.)

2 would mean, “I’m standing behind this.”

3 would mean, “I’m highly committed to this. I could take lead on making sure it happens.”

A couple of the alternatives got 1’s but most of them were 2’s and 3’s. The positive thing about getting some 1’s was that people felt it was ok to say ‘No’. To me, this was a healthy sign. After counting the 2’s and 3’s in the rest of the alternatives, we were left with one winner in each category.

1. Well-being: “Getting more constructive feedback.”
2. Productivity: “Discussing requirements and design before implementation.”
3. Quality: “Getting more stable test-environments.”

Gather data

I then asked the participants to pair up again, but in new constellations. After telling them about Jerry Weinberg’s Rule of Three and the Iroquois Rule of Six, I asked them to come up with six plausible explanations to why we hadn’t already solved the three challenges historically. I asked for six reasons because:

“for each apparent phenomenon, devise at least six plausible explanations, every one of which can indeed explain the phenomenon. There are probably 60, but if you devise six, this will sensitize you to the vast array of potential options and prevent you from locking in on the first thing that sounds “right” as The Truth. This attitude supports the mind in discovering new ways of perceiving, keeping our perceptual biases in check while allowing them their say.”

After a while someone said: “We’re on par with the old dude now but we’re still getting our asses kicked by the Indians.”

Since we were running out of time I let them get away with the reasons they had managed to come up with by then. It varied between the challenges and the groups but all of them had come up with several good explanations for each challenge.

Generate insights

After getting all possible explanations to why we hadn’t already solved the challenges in the past, up on the wall, the participants did an affinity mapping. They got a handful of different groups under each challenge; “Lack of knowledge”, “Lack of time”, “Lack of common process”, “Lack of communication” etc.

Decide what to do

Based on the challenges and the insights on what had been stopping the team in the past, we had a discussion on what we could do to meet our challenges in the near future. We agreed on two actions before we ran out of time:

1. A weekly feedback forum at Friday coffee.
2. Regular pre-planning meetings with representatives from all disciplines.

Closing the retrospective

I finished off by thanking everyone for their active participation and asking them for some thoughts on the retrospective and the format. The feedback was very positive and they felt that this was something that they should have done all along.

My learnings

As always, time is almost never enough. Guiding people through a process like this while at the same time giving some space for discussions takes longer time than expected.

Setting a challenge at the beginning of the retrospective and then looking back to see why we haven’t met it before worked very well. The one problem I could see with this was that we only focused on problems when looking back. I’d like to also look at strengths and positives. I might compensate this by doing an Appreciative Inquiry retrospective the next time.

My commitment voting-scheme worked better than I had expected. I’ll definitely try this more in the future instead of dot voting.

Edie

Tonight, just a month after I got the news about Charlie Seashore passing away, I read that Edie Seashore had followed him. I did not know Edie or Charlie very well, but I did have the privilege of meeting them for a week in Cape Cod last summer where they taught the course “Strategies & Skills for Consulting, Coaching, Change”. The way they shared their experience and wisdom during that week made me feel like I had known them a lot longer though.

Edie and Charlie’s signature combination of wisdom with humor and a love for each other and what they taught made them seem inseparable. Both of them were strong individual personalities that made deep impressions on me but when they spoke in front of us it was clear that they weren’t only Edie and Charlie; they were Edie AND Charlie, a union so much more than its parts. As sad as I am to hear that Edie is no longer among us, it seems natural that the bond between them was this strong.

I am not a religious person, but I have no difficulty imagining Edie and Charlie still being together in a good place. I am so happy that I got the chance to learn from such wonderful persons. Thank you!

Edie & Charlie at Cape Cod 2012