Have you heard of the Candle Problem
? If not, you should Google it. I learned of it over this past Christmas break while driving to Michigan, listening to a TED Talk on motivation. I know what you're thinking, and yes, I am that interesting. But you should keep reading. The speaker, Mr. Dan Pink, described a study in which a scientist conducted a social experiment in problem solving to study incentives. I'm not interested in "motivating" my team or giving "incentives," but I am into conducting social experiments on them. Before you go and judge me, you should know that it is OK -- my wife is a psychologist. This means that I could not tell her about the experiment until after it was over.
What I am interested in, though, is trying to get my Agile team to be more Agile. A lot of you reading this are probably thinking, "How could you be any more Agile? You sit in a pod with several developers, business systems analysts (BSA), and accountants. You do stand-ups, sprint reviews, retrospectives, and grooming. You have goofy posters on the wall. You pretty much exude a must-like Agile scent and walk with a Scrum-type swagger that any rugby team would envy." That is all true. However, I still find that "the business" is writing the requirements, and IT is doing the configuration and development. Then development is passed back to "the business" for testing. Lather, rinse, and repeat. We may package it as something different, but this is Waterfall.
Have you ever noticed the professional background of your peers? I was an accountant in my former life, so I will use accountants as an example. Many accountants went to top colleges; some went to the University of Michigan. Many worked in public accounting. And we all have worked on similar projects, with similar challenges. My IT friends are similar in that they have homogeneous backgrounds. What I want for my team is to become Agile. I want us to approach problems together with all of our different backgrounds, education, and experiences. This leads me to think that I could use the Candle Problem to illustrate this initiative.
So what is the Candle Problem? To summarize the activity, you give people a box of tacks, a candle, and some matches. Then you ask them to affix the candle to the wall in such a way that, when lit, no wax drips onto the floor. So I divided the team into three groups. A group consisting only of IT (code name "Table 9"), one of only Senior Responsible Officers (code name "Screech"), and a group of both IT and SRO (code name the "Odd Couple"). I gave them the problem, the supplies, and four minutes to complete the challenge.
So what happened? Oddly enough, the Odd Couple won. The team that was the most diverse in thought beat the other two homogeneous teams, albeit by a very slim margin. I admit that this is not a scientific study. We had a very small sample size and the wrong kind of candles and matches. But the result was still interesting, not only because the team with business and IT won but because of the three different approaches the teams took. Each team tried to affix the candle to the wall in a different way. And all three teams "solved" the problem within the four minutes -- and no fire alarms went off! So it was a great day!
The best part of the activity was the discussion. I think that everyone was surprised by how each team solved the problem differently. The results don't mean that I am going to go write code, developers will be documenting T-Accounts, or that the BSAs are going to do whatever it is that they do well. What we all realized, though, is that it's not up to each individual team to come up with solutions in the context of our own silos.