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.

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.

Brainstorming With Colonel Mustard

I was recently asked by a colleague to help with the format for a brainstorming exercise. The purpose of the exercise was to find new ways to reach an audience for the content our organization was developing. Both of us wanted to try something new and we really wanted the participants to start thinking outside of the so called box. What we came up with was a two part workshop that I’d like to share.

The first part was a traditional Post-it-exercise run for three different themes. First we asked the participants to list as many aspects as possible of the content we developed. They were asked to write it down on a certain color of Post-its using just one or two words. We then asked them to do the same thing on another color of Post-its but this time to list different cross sections of possible audiences; whom to reach out to. The target audiences could be sliced according to roles, geographical belonging, age or any other grouping. Finally the participants got to write down different channels for reaching out on a third color of Post-its. We got all kinds of fun suggestions; competitions, courses, lunch walks, blind dates, printed t-shirts etc.

Colonel Mustard

For the second part we wanted to use an element of randomness to get the participants imagination going. Inspired by the game Clue; you know the detective game were you have a bunch of suspects, different murder weapons and a number possible crime sites. In the game, the players randomly combine a suspect with a murder weapon and a crime site by pulling one card from each pile. They then try to deduct which cards have been selected by questioning each other. Finally someone realizes that it was Coloner Mustard in the library with the candlestick.

In our workshop we now had three big piles of Post-its containing What, For Whom and Channels. We divided the participants into groups of two and asked them to randomly pick one note from each pile and try to concretize the mix of cards into an actual event. So if a group picked the cards Content A, redheads and blind dates; they then had to come up with an idea for how to sell Content A to redheaded people by arranging blind dates. The combinations that came up brought out a lot of laughter but it also generated tons of new ideas for how to market our stuff to different audiences. Surprisingly few combinations had to be completely discarded and people came up with really imaginative events from the random combinations they were dealt.

From this experience, I can really recommend trying an element of randomness when you need fresh ideas and have a problem that can be sliced in different dimensions like this.

Self-organization before bedtime

When I was a kid, back in the twilight between the late 70’s and early 80’s, a bunch of us neighborhood younglings used to meet up after dinnertime at a small field to play together. Not a lot of planning needed, a couple of us would just agree to meet and then the word spread. One of us brought a soccerball and someone else brought a tennis ball and a bat for rounders. Most of us knew each other to some degree but every now and then a new kid had moved in or someone would bring a friend from outside. We were usually about 5-15 kids and we used to decide there and then on what to do; soccer, rounders, hide and seek or some other game. If we decided on soccer a couple of us would take our sweaters off and then we used them as goal posts. Someone would volunteer to be goalie or we’d decide to take turns. And then we played until our parents called us in for bedtime.

Last night I got to experience something similar once again. My good friend Daniel called a couple of days ago asking if I wanted to come along for night caching with him and some other guys. I like geocaching but for me it’s mostly about getting to be outdoors with the kids every now and then whereas Daniel and the other guys have made this hobby into an artform and a gadget sport.

Anyway, we met up after dinnertime, but this time it was initiated by an email and then someone called someone else and someone brought a friend and we finally ended up being seven men in the rough range of 35-50 years old. Some of us knew some others quite well, other’s had met briefly and for me this was a totally new crowd except for Daniel. But we had one common goal; to follow three reflective trails in the woods and solve puzzles along the way that noone had managed to solve before us. We would do this in order to find a fourth trail and the final prize; the FTF (being the First To Find the cache).

Armed with head lamps, UV-light, cameras, pens, paper, GPS’s, smartphones and some candy we set off into the rainy darkness to find the solution to this riddle somewhere in a forest west of Stockholm.

Since everyone else were a lot more experienced than me in this area, I decided to observe and learn about this type of geocaching more than I would contribute to the solution. I did learn a lot about night caching but the self-organization and the self-steering that I got to observe and be a part of was beyond what I could have imagined.

The level of problem solving and cooperation needed to succeed was definitely comparable to building quite a complex piece of software (though more limited in size and time). Without anyone being appointed manager of this group, everyone quickly found roles to fill where they could contribute to the team. Not a lot of words where spoken regarding what to do, it just happened. A couple of the guys took the lead and started looking for the next reflective marker, a couple of us walked in the middle marking the ones we had found and a couple of guys followed after looking for clues that could help us solve the puzzle. Someone called out an idea, someone else went online to look for information. Someone tried out an idea, someone else was already working on the next hypothesis. Not a minute was wasted, and in what I would say was the shortest timeframe possible, without hurrying, we solved the puzzle piece by piece. Reiterating pieces of the puzzle where the first idea didn’t pan out but never getting too far astray since we were quick to put our ideas into practice.

Three hours later, after being the first people ever to sign the log, the seven of us could pat each other on the backs and go back to our cars and drive home to our families for a good night’s sleep.

When we were kids, we were united by the common goal of having some fun between dinner and bedtime. Last night we were united by the common goal of being the first ones to solve a complex problem. In both cases we succeeded very well with our missions, we had fun doing it, noone needed to manage us and we all found ways to be useful.

Do you remember what this felt like when you were a kid? That feeling of being creative, contributing to the game and not wanting to go home when your parents came for you. Do you want to experience it again? We should all be able to have that same feeling that kids have between dinner and bedtime. Every day. From 9 to 5.

When operations are dancing a jig on my doorstep

I wrote in my previous post about the Scrum team I’m working in as a ScrumMaster and that we’re closing in on our first release to production. At this stage a lot of the work is related to getting production environments up and running and our user stories have taken on a more technical format and are formed more by the team than the Product Owner. Our PO had a story asking for a production environment but that one was way too fuzzy for the team to take in so they had to break it into smaller stories/technical tasks. A lot of this work was done on the fly during the planning session and we needed to find defintions of done for the stories as they were forming.

The task of finding good definitions of done proved to be harder than anticipated for these stories. After a while I realized that what we were specifying tended to be more of a list of tasks than acceptance criteria. So we backed up the value chain by asking “Why” we wanted to do something and started arriving at better definitions of done. However, the crown jewel was when we were discussing the job of getting outsourced operations to monitor our application. What was the definition of done here? Putting the order for monitoring services in the mail? Getting a reply to our order? Having a signed contract? We weren’t really getting anywhere until all of a sudden one of the team members spoke up:

“I want to turn off one of our services and when I see operations dancing a jig on our doorstep, that’s when we’re done.”

I damn near got a tear in my eye hearing this suggestion. This is the kind of thinking that we need when we measure things. Whether it’s a level of service, quality or productivity we want to measure we always need to begin by looking at what we want to accomplish. We can’t demo usability by showing a pretty UI, we need to put a user in front of the UI to demo usability. We can’t demo quality in number of bugs found, we must demo quality in a fit for use product that is stable under usage and over time. And if we want to demo our ability to handle problems, we can’t do that by waving a contract. We demonstrate our ability to handle problems by handling a problem.

This episode reminded me of a story an aquiantance told me ten years ago about his neighbor. The neighbor had a burglar alarm connected to a security company. The security company promised in their service to arrive at the house within 20 minutes of an alarm. Twice every year this neighbor set the alarm off. He then pulled out a lawn chair, put on ear protections and sat down with a timer in his hand and when the security company arrived after half an hour or fortyfive minutes, he filed a complaint and got the service for free for another six months. This guy knew what the definition of done was; he also waited for operations to dance a jig on his doorstep.

If you want to measure or demo some qualitative aspect, don’t settle for the easy way out and try to quantify it. Put it to the ultimate test, that is the only way you’ll ever know for sure that you’ve done something right.

For whom was the sticker made?

A couple of days ago, as I was grabbing my bag out of the overhead compartment on the quite small plane I had taken between Newark and Raleigh/Durham, I noticed a sticker in the back of the compartment. Most planes I have flown with were bigger and I’m just not tall enough to see that far in so I don’t know if the sticker is always there but in this plane it was at least. The picture I managed to take is quite blurry but what it says is: “MAX. CAPACITY 60 LBS/27 KG”.

Great, they don’t want the compartment to fall down on the head of some poor schmuck sitting under it.

I don’t know what’s wrong with me but I immediately wondered why they put that sticker there. What is the difference between having that sticker and not having that sticker?

Let’s pretend you’re a passenger and you are the first one to put something in the overhead compartment and you actually manage to see the sticker. What goes through your mind? Probably nothing much. Most of us have a bag that weighs less than 10kg but that doesn’t really matter because we don’t know what it weighs anyway. So you put your bag up there. Next person comes along. If she can still se the sticker after you’ve put your bag in there, what will she think? Probably that her bag is lighter than the limit. She has no idea how much your bag weighs and she most certainly won’t take it out and try to estimate the combined weight so she puts her bag in there as well. If there’s still any room up there, no one will see the sticker because of the bags and jackets already there and they’ll keep loading their bags.

Let’s pretend that the airplane manufacturer put the sticker there because they were concerned for the safety of the passengers. Jerry Weinberg uses the expression that you should eat your own dog food, meaning that you should try your own products for yourself before exposing them to your customers. If the manufacturer had actually tried to board the plane and recorded how the sticker changed their behavior they would probably have come up with zero.

But what if the sticker wasn’t even the manufacturer’s idea. What if it is some government agency that is looking out for us, the passengers? Did they make a rule that says that the manufacturer must make sure that no one gets an overhead compartment in their head? Did they express it in such a way that no one will get an overhead compartment in their head? They might have said that the manufacturer is liable for informing the passengers about the maximum load. But they certainly did not say that the manufacturer is liable for making sure no one gets hurt. Because if they did, that sticker would not have been there.

Now I don’t know who decided that there should be a sticker there and for whom it was made and
Therefore, I send to know
for whom the sticker was made,
it wasn’t for me.

Enough of paraphrasing John Donne and back to the game. If the purpose of the sticker truly is to save people from getting an overhead compartment in the head and not just a way of keeping the manufacturer out of court when someone has been hurt, then I consider it to be an example of poor problem solving and I’m more interested in good problem solving so I’m asking you, dear reader:

What would you have done to prevent people from overloading the overhead compartment?

The Magic Carpet of Crap

A couple of days ago, I read a blog post entitled “Code == Crap” or something to that effect. I didn’t agree with most of the post but the phrase “code is crap” really struck a chord with me.

Jerry Weinberg wrote in his book The Secrets of Consulting:
“No matter how it looks at first, it’s always a people problem.”
I agree with Jerry. All the problems that we try to solve are basically people problems at the root, and software will never dissolve* these problems (how I wish that everyone would take a couple of minutes to consider this).

Software will at best provide a resolution to the problem while at the same time giving us a new stack of problems to handle. This is why I think that code == crap and why I think that we should do as little of it as possible.

If you consider your most recent software project, how many of the 5 Whys do you have to ask before realizing it is a people problem that you’re trying to solve with software? I’ve tried it with a bunch of projects and problems now and never had to ask “Why” more than three times before a people problem has surfaced. Now, in many cases software is one of the least painful ways to work around a given problem but it has never so far, in my experience, dissolved any problems. Software has provided us with a patch or a workaround but the root cause of the problem still exists. And to make matters worse, we now have a bunch of new problems, related to the software we created, that we must tend to as well.

I’m a developer at heart and I love to see a beautiful piece of code, but only a fraction of the effort put into our software projects is related to actually solving our customers problem. We spend a majority of our time handling new problems that are related to our recently found “solution”. Documentation, quality assurance, project management, all maintainability issues etc are activities to make sure that our solution will cause as few new problems as possible; now and in the future.
All this work and the original problem is still out there!

The minute our code stops working, our customer is not only left with the original problem, but he now also has a truckload of files, tools and documents that we sold to him.

There’s no question that software often is a good thing. Software has improved our lives in so many ways. But the old problems that we tried to solve still lurk out there. We’ve used code to hide root causes and to sweep many a stinking problem under the carpet. So the next time you feel the urge to write some code, please take a minute to ask yourself just a couple of the old 5 Whys in order to see where the actual problem lies and to consider if software really is the best way to handle it.

The magic carpet of crap, sorry I mean code, can only hold so many problems before it gives us the ride of our life.

* In The Art of Problem Solving, Russell Ackoff makes a distinction between solving, resolving and dissolving problems:
“To solve a conflict is to accept the situation and find the best one can do within it. To resolve a conflict is to accept the situation and find a distribution of gains and/or losses among opponents for which they are willing to settle. … To dissolve a conflict is to change the situation in such a way as to remove the conflict.”

I like to use these distinctions when talking about different levels of problem solving because they often help us see beyond the obvious.

Don’t hire creative people

Has the innovation in your company come to a halt? Are there no creative individuals left in your organization? Are all your employees stiffs without any imagination?

Whatever you do, don’t hire any creative people!

Did you see an opportunity to hire a colorful person full of new ideas? Please send him/her away. Leave the poor bastard alone.

You can not give your organization a vitamin injection by hiring inspiring people. You’ll only drag them down to your own level and the result will be an organization that’s still in rigor mortis but with another soul added to the tab.

You can not buy innovation, you have to design for innovation. Your organization is already full of creative inspiring people but your processes (or lack thereof) for innovation and creativity are holding them back. You need to design an organization and processes where new ideas are cultivated and appreciated. You need processes where the new ideas are caught, valued, implemented and nurtured in a swift and agile manner. Mistakes must be considered equally valuable as successes, or the full potential of your organization’s creativity will never be unleashed. It’s not enough to give employees some room for experimentation; the entire system needs to be explicitly designed for creativity.

Everyone can be creative under the right circumstances but no creativity will survive a badly designed system.