TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Thinking Inside the Box



A StickyMinds.com Original
Article Picture
Thinking Inside the Box

By Naomi Karten

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: The problem with urging outside-the-box thinking is that many of us do a less-than-stellar job of thinking inside the box. We often fail to realize the options and opportunities that are blatantly visible inside the box that could dramatically improve our chances of success. In this week's column, Naomi Karten points out how we fall victim to familiar traps, such as doing things the same old (ineffective) way or discounting colleague and teammate ideas. Thinking outside of the box can generate innovative and ingenious ideas and outcomes, but the results will flop when teammates ignore the ideas inside the box.


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
Naomi Karten (www.nkarten.com) has delivered seminars and presentations to more than 100,000 people internationally to help them manage customer expectations, establish service level agreements, and strengthen relationships with customers and with each other. Her books, Communication Gaps and How to Close Them and Managing Expectations offer practical tools, techniques, and advice for carrying out projects, delivering service, implementing change, and strengthening teamwork. Her handbook, How to Establish Service Level Agreements, and her SLA guides help organizations worldwide establish successful SLAs. Readers describe her newsletter, Perceptions & Realities, as a breath of fresh air. Before forming her training and consulting business, Naomi earned degrees in psychology and held numerous IT positions. Contact her at naomi@nkarten.com.

Back to Top
 
 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Phil Boettge 1/24/2005

I can't count the number of times I've heard engineers say things like "When it comes to doing process or turning out a product on schedule, we gotta [sic] turn out the product!" Then the resulting panicked scramble near delivery becomes the search for "thinking outside the box" -- meaning "find another shortcut -- out of the mess we steered ourselves into." Engineering rests on principles. We ignore those principles at our own peril.

 
 
Comment:    
by Max Dellinger 12/30/2004

Totally agree that "outside the box" is meaningless unless you have an understanding "inside the box". Buts whats a client to think and what's the status of the tester involved if all the client gets is "software that works", without the proper catch phrases. Worst of all what will we use to impress our clients if we go back to "inside the box" (Perhaps, "Inside the Box, Revisited). Great article, Naomi, and thanks for relaying this to everyone.

 
 
Comment:    
by Danny Faught 12/12/2004

Hi, Naomi, nice article. Just to make sure I understand your point - where is the box?

 
 
Comment:    
by Tanmay Vora 12/9/2004

Hi Naomi; Thanks for an insightful article. In my opinion, if work processes are well documented and aligned to business requirements, "out-of-the-box" thinking is really not required. Looking out without looking within is like looking for a flight service where even bus service is not in place !!

Author's Response:
12/10/2004    
Hi Tanmay. I agree, and I like your bus/flight analogy! Outside the box thinking can sometimes play a role in helping an organization take a huge leap forward or gain an advantage over the competition -- at least temporarily till the competitors do a copycat and catch up. But most software organizations would go further faster by focusing on the processes that are lacking. Yet, it’s these very organizations that seem to see outside-the-box solutions as the path to greater effectiveness.

 
 
Comment:    
by sethu rajan 12/8/2004

Thanks for reminding us that many a time we forget "sticking to Basics , well proven methods " in the search for flashy new ideas

Author's Response:
12/9/2004    
Hi Sethu. I think you hit the nail on the head. People view “outside the box” thinking as flashy, especially compared with the un-flashy (but often more productive and effective) basics.

 
 
Comment:    
by Andrew Raybould 12/7/2004

Precisely. In fact, forget the box; just think.

Author's Response:
12/7/2004    
Andrew, well said! Concise and to the point!

 
 
Comment:    
by John Daughety 12/7/2004

I enjoyed reading your article very much, especially since it rings so true with a recent situation for me. I was test manager for a development team that had no process at all - there were no design specs, no one defined user requirements before they started coding, and new features were added to a release the day of the final build. My mandate was to fix their quality problems by thinking "outside the box." Actually, they had already defined "outside the box" for me - automated testing. I cannot imagine a worse environment for implementing automated testing! While we did get some tests automated and some developers started writing...Read On

Author's Response:
12/7/2004    
Hi John. I’m glad you enjoyed my article. What an incredible experience you described! This team sounds like a case study of how-not-to. It makes me wonder if the more process-less a team, the more likely they are to describe the improvements they seek as “outside the box” – an indication of their lack of awareness of the basics.

 
 
Comment:    
by Frits Bos 12/6/2004

Naomi, you are absolutely right on. People confuse "out of the box thinking" with "lateral thinking", and as a result it seems that many project requirements are more or less ignored for more creative options. Nowhere is this more obvious than in QA testing, where people keep inventing new tools for test automation when the root problem is the effort to create test scripts in the first place. Lateral thinking is to act upon that specific challenge to see if an existing process cannot be improved upon, whereas out of the box thinking puts a GUI on top of an already unwieldy process (like IBM Rational Manual Tester, for example). The...Read On

Author's Response:
12/6/2004    
Hi Frits. Bloatware – yes! People often seem driven toward complexity in devising solutions. Thanks for describing the difference between out of the box thinking and lateral thinking and for pointing out the possible consequences in the QA testing context.

 
 
Comment:    
by Johan Max 12/6/2004

Steven Covey has already point these out in his book "7 habbits of highly effective people." He covered this topic at public winning. There are 3 key points according his jargons : 1. try to understand the other first 2. win win situation 3. sinergy The Bible also covered your point but it's not so easy to understand. It 's so broad. Perhaps we should read the Bible and inject its values into SRLC (software revolution life cyle). The jargon SRLC is my own jargon after reading an IEEE article. Here it is (this is not an exact copy). "Let learn from nature. Why it's so complex ? Because it grow/ evolute. So must the software .Read On

Author's Response:
12/6/2004    
Greetings Johan. Thanks for your comments. There are certainly many sources of wisdom and we’d all benefit from by introducing them into the software environment.

 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Seapine




STARWEST 

Agile Development Practices