Thinking Inside the Box

[article]

If I had a doughnut for every time someone advocated thinking outside the box, I wouldn't be able to squeeze inside the box to point out the flaws in this idea.

I encountered an excellent example of flawed inside-the-box thinking during an exercise a group of software professionals carried out. The purpose of the exercise was to help them reflect on problems they'd experienced in previous projects that kept them from completing the projects successfully. The group was divided into five teams. Each team then tackled the same project: using the materials provided, they were to build a birdhouse that met specified requirements. Like many of their software projects, this one was characterized by ambiguity, unclear priorities, mind-changing customers, and of course, a tight deadline.

When the time allocated for the project was up, the members of each team examined what the other four teams had come up with. They quickly saw that they had all tackled the project differently, and some made more progress than others had. What especially stood out for them as they reviewed each other's work was that every team had missed opportunities to accomplish more and to do so in less time without sacrificing quality.

The facilitator asked the five teams to reflect on their experience of this exercise and to create a list of things that they might have done differently to achieve a more successful outcome. Within ten minutes, the teams came up with a long list of possibilities. In round robin fashion, the teams then reported what was on their lists. And on each list was "We should have done more thinking outside the box."

Who can blame them for this reaction? There's a certain pizzazz to the idea of coming up with imaginative techniques and ingenious solutions. But every team had fallen woefully short in thinking inside the box. Proof of this fact was that almost all the ideas on their lists—ideas that would have enabled them to succeed with the assignment—resided smack dab inside the box.

Their ideas included:

  1. Listen to each other's suggestions
  2. Don't be so quick to dismiss each other's ideas
  3. Challenge assumptions
  4. Create team norms that improve working together
  5. Build a relationship with the customer before building the product
  6. Consider the customer's perspective when asking questions
  7. Spend more time talking with the customer—and listening
  8. Spend more time planning before starting to build
  9. Ask more questions about what's expected
  10. Ask better questions about what's expected
  11. Draw from each other's strengths
  12. Collaborate with other teams and learn from each other
  13. Consider what we've learned in other similar projects
  14. Consider what we've learned in other projects unlike this one
  15. Relate this problem to other problems team members have had experience with
  16. Have a team member observe how the team is doing and give feedback
  17. Seek advice from others who have already undertaken similar projects
  18. Stop periodically and assess how the team is doing

Great ideas—and not a single one required venturing outside the box.

Having observed their birdhouse-building exploits, I asked the teams how many of these ideas reflected things they knew going into the exercise. "Nearly all of them," they said. "And how successfully do you act on these ideas in your software projects?" I asked. "Not very" was the consensus.

Despite their extensive experience, most team members admitted they forgot, discounted, or ignored what they already knew during both the exercise and their software projects. Strikingly, one of the most productive, very-much-inside-the-box, things the teams could have practiced was to call a time-out to draw up the lists (which they had so rapidly generated afterwards)—and then follow the advice captured in the lists. In creating these lists as swiftly as they did, they demonstrated they already had a wealth of knowledge and expertise. But it wasn't till they reflected on their experience after the exercise ended that these things we could have done became obvious.

Outside-the-box thinking can generate ideas for processes, techniques, and outcomes that are innovative and WOW-generating. But the resulting ideas will flop in a climate in which the people involved ignore the inside-the-box ideas such as those listed above.

The next time you hear someone urge outside-the-box thinking, see if the situation is one in which those involved have overlooked the possibilities inside the box. And whenever you hear a claim about someone having done outside-the-box thinking, see if you agree. Or might the thinking have actually taken root well within the box?

Our challenge is to look around from our perch inside the box and ask, "What options and opportunities are right here for the taking?"

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.