Functional Fixedness

Let’s say you have a candle, a box of thumbtacks, and a book of matches. Can you figure out a way to affix the candle to the wall in such a way that when lit, the wax will not drip onto the floor?

There’s a psychological bias that sometimes prevents us from seeing possible solutions that are right in front of us. One common bias is called functional fixedness.

Last summer, I was lucky enough to spend a number of weeks in Alaska. As part of this trip, I got to spend a bit of time on the Mendenhall Glacier, where some beautiful glacial water happened to be flowing. Not expecting it, I didn’t have a cup or glass or container to use to drink the water. It was a little below the surface, so lying down and putting my face directly in the water wasn’t really an option – I guess I could have made it work. But being the creative person I am, I used a flash diffuser I happened to have in my camera bag, while others who were with me couldn’t enjoy the pure, ice cold, crystal clear, glacier water.

When it comes to innovation, people and businesses are constantly hampered by functional fixedness (and other biases), which causes us to overlook elegant solutions hidden in plain sight.

Consider deflating a soccer ball and using it as a bowl. Why not?

Sometimes, the words we use constrain our thinking. It’s important to use the most generic words when we first start talking about a problem or an opportunity.

There’s a great quote about buying a drill. The quote is that people don’t want a drill; what they want is a hole.

But I’d like to take this a bit further – we don’t really want a hole. What we want is somewhere to put in a bolt. But even that isn’t what we want. What we really want is to bolt pieces of wood together. And we could explore that further by understanding why we want to connect those pieces of wood. Maybe there’s a better solution. Maybe not. What if I changed my goal to “connect” pieces of wood? What if I used the word adhere. Or laminate. Or join. Do different possibilities come to mind when I simply change the word? A functional fixedness can be caused by how the problem is framed.

The most dangerous words I hear in organizations are “that’s how we do it here”.

By the way, here’s a solution to the candle problem I started this post with:
If you empty the box of thumbtacks, you can attach the candle to the inside of the empty box with some melted wax, and then tack the box to the wall. The box acts as a shelf that supports the candle and catches the dripping wax. Because the box is presented as simply a container to hold the tacks, it’s often difficult to see it as anything else.
It’s Duncker’s Candle Problem.

As you’re going through your day, challenge those things you consider absolutes.

Safe to Fail

I’ve just returned from speaking at an Agile conference in Winnipeg. Yes, Winnipeg in November. It actually wasn’t too cold, and the quality of conversations were amazing, so all-in-all, an amazingly worthwhile and valuable experience to learn and share.

I wanted to think about failure this week. Something I’m pretty familiar with!

In order for innovation to occur, we need to be in a safe environment. Only when it’s okay to get something wrong will we be willing to push the boundaries.

I often hear from folks who work in financial services, insurance, health care, and even telecommunications say that we can’t really take risks. So what’s the alternative? If we’re going to dream and make a real impact, we can start be making really small experiments. We need to be pushing the boundaries in a way that doesn’t put our customers at risk, and doesn’t put us at risk. So we need to find safe ways to fail. We need to encourage each other to look at tiny bits of work that we’re doing, and look for those improvements that might not revolutionize our work and industry. But if we keep at it, I believe we’re likely to find that the sum of our improvements can make an impact.

I participated in a Lego Serious Play session in Winnipeg. I was having some fun creating a model of what I would do with team members who let me down. The model shows that person being pushed off the top of a tall tower by another team member.

Have you ever worked in an environment when you made a mistake, and got punished? Maybe it was significant enough that it resulted in a lower performance review at the end of the year. Maybe it was by public shaming. Maybe it was just an idea that wasn’t aligned with your manager, and you were told that in a meeting.

Regardless, how likely are you to take another risk in that environment?
Yeah. Me neither.

When someone takes a risk through a controlled experiment, we should celebrate the learning that comes from that experiment. No matter the outcome of the experiment, because learning is an outcome that can be used to guide and inform the next experiment.

If we’re running huge experiments, with months of investment, and weeks to roll back if we find an issue, there’s a huge risk! Not only is the initial outlay expensive (we’re risking a lot of money, time, and effort to begin with), but we’re also risking the fact that no one might want to use whatever it is we’re creating for them. Oh, and by the way, we’re not learning anything along the way.

In project management, we talk about the “iron triangle”. That is, there are three elements that need to be managed during a project – they are Cost, Quality, and Scope. (There’s a joke here that on almost any project, you can pick two of them at the expense of the third). But that’s not the point I want to make. Imagine if I deliver on all three of those elements – I deliver exactly what was asked for (scope), I deliver it with on time and on budget (cost), and I build it perfectly, in a way that it’ll last forever (quality). Sounds like a successful project.

But wait a second… If no one uses it, if it creates no additional revenue, if it doesn’t help with customer satisfaction… Would you really call it a success?

If we have a hypothesis, we need to look at running the smallest experiment to validate it (or disprove it).

Once we’ve validated it, let’s invest more money and release the next experiment.

Lather, Rinse, Repeat.

But in order to enable this, we need to have a safe environment to encourage experimentation. And failure. That creates opportunities for learning.

And that seems like a safe way to lead to success.

#NoEstimates

I’ve been reading and writing about #NoEstimates for over a year… Along the way, I’ve found some great people with some great thoughts with opinions and experience both for, and against. I’ve worked on projects which have been estimated and planned up front, projects which have been estimated but no detail plan completed up front, and projects where the work has just started. I’ve had successful projects delivered in all of those contexts (on time, on scope, on budget, to the satisfaction of all stakeholders – NPS > 80, for example).

What strikes me is that throughout all of the discussions, primarily on Twitter (which is possibly the worst place to have a complex discussion of ideas), is that there remains an Us-vs-Them mentality. Both by those in the #NoEstimates camp, and by those in the No #NoEstimates camp.

In my experience which I’m sure won’t apply in every situation, when the business and engineering teams work together — and really mean together — I’ve seen the need for estimates diminish very quickly. The need for up-front planning diminishes. The opportunity to find solutions to problems is amplified, and the solutions are beyond what was asked for, or imagined, when the project started and there was minimal knowledge.

One of the arguments that bothers me the most is when I hear “you’re being irresponsible with other people’s money”. Or something along those lines. I don’t view it that way. It’s not us and them. It’s all our money, and we need to figure out how to spend it together. We need to be working together, with a shared understanding from all perspectives, instead of being responsible for simply implementing what someone else decides we’re going to do. My point is that it’s not your money and we deliver something. We’re all in it together. The developers, testers, release engineers, DevOps, BAs, CIOs. And everyone else.

When teams eliminate the Us & Them way of thinking, collaboration happens, trust develops, and new ways of thinking about projects, products, and problem solving can emerge. The way we’ve done things for decades no longer applies.

If, ten years ago, I told you that we could release to production on an hourly, daily, weekly basis, there are those who would have screamed bloody murder! How could you possibly release without a month of hardening? Where’s the smoke testing? What about time for UAT – how could we be sure the business would accept what had been developed? How irresponsible would this be? How could you be such a cowboy with other people’s money, putting that code into production? Hell, it used to take days or weeks, if not months in some cases, just to get the hardware up and running. That’s no longer the case. In ten years from now, I wonder if we’ll look back on estimates the same way.

I’m not sure if estimates can be eliminated entirely. But either way, I’m not going to stop exploring options and discussing alternatives.

Just as an aside, one of the projects I’d say was my most successful, personally, was a small ~$450K fixed-price, variable-scope project. We delivered it with significantly more functionality that had originally been discussed, about 20% under budget, and about 22% ahead of schedule. The client who paid for it was beyond thrilled. We worked our asses off, but never really put in any overtime – yeah, an hour here or there, but then we also took time off along the way. We understood the objective. We worked together to achieve that objective. And, we estimated nothing.