Baking “half-baked” ideas

My dad is famous for writing books with crazy ideas:

* A seagull who breaks the rules of the flock to experiment with limitations of flight, only to realize there are none.

* A messiah who can levitate wrenches and heal people just by looking at them, but gives it up because he just wants to fly and fix airplanes.

* A flight instructor who realizes that changing our lives can be as simple as accepting new suggestions into our consciousness, as if all we need to do is agree to play along with the hypnotist onstage.

He’s made an amazing living on writing books like this.  He hasn’t had to hold a job since I was born (1968) because ideas have been his bread and butter — er, more appropriately, the wind beneath his wings. Money has flowed into and out of his life, but his ideas have always been his greatest asset, always lurking backstage, ready for him to turn them into a best-seller.

That *idea* itself, is contagious, so I felt compelled to talk about what happened when I tried to develop 3 of my half-baked ideas as a test manager last year …

Idea #1: When fast-food chain McDonald’s came out with its yearly Monopoly promotion, I got a little game board and posted it in my cubicle.  It was a fun little thing I wanted people to help me with.  If you went next door for a Big Mac, give me your little game tokens and help me fill in the board. But one of my staff knew I was a testing geek and dared me to find a testing analogy for McDonald’s Monopoly.  Somehow, it only took a few seconds for an idea to hit.

“You know how Baltic and Mediterranean are the least expensive properties, and Boardwalk and Park Place are the most expensive?  Maybe we could organize tests like that.  Color-code them by value.  There you go.”

I amazed myself.  The idea came from nowhere and it was kind of a joke, but I liked what I had just said!  A splash of color may actually be valuable to see on a spreadsheet — all of our tests, colored by value instead of boring black and white cells.

Ben shook his head and smiled, called me “the master” and said I had done it again. 

“Wait,” I said.  “I’m serious.  This idea might have merit.” 

I told him to contact a colleague named Robert Sabourin who uses color in his testing exercises to help testers do test design — Failure Modes (red), Capabilities (green), Inputs/outputs (purple), White-box testing (white), etc.

I gave Ben an assignment, playfully.  Write me a little experience report on this idea and whether it actually might work for us. And you know, he did.  He called Rob Sabourin and he came up with what seems to me to be Color-Aided Test Design.

Did we use it on our projects?  No.  I’m not sure why.  We got busy, I guess.  We knew the territory and rarely looked at our test plan spreadsheets anyway. Was it a failure of an idea? No, and here’s why.

About a month later, I asked Ben to give me the list of tests we ran every cycle (6 weeks), then the list we should place emphasis on when we’re 3 – 5 days out from ship, then the list of tests we run every day, then the tests we run on every build, then the final Gold tests on ship day. He came back with an idea — a pyramid representation of those tests — and — he color-coded it. 

The 6-week tests were the base, colored in Sapphire; the 3 – 5 day tests were the next level up in Emerald, the one-day tests were a layer above that in Ruby, the tests we did every build were over that in Gray (known as the BVT), and the apex was gold for the tests we did with Gold bits — the release checklist.  To me, this was the keeper idea, and I used it all the time when talking to management about where we were.  It wasn’t long before all I had to do was speak about which color we were in.

—–

Idea #2: I used to manage by walking around to my staff’s cubicles and checking in every now and then. But I noticed some of them sighing when I’d do that, as if to say, “Hey, don’t bother me.”  Even though they said it was ok, I thought there could be a better way.  Then an idea came to me — index cards.  Maybe if each of them took a stack of index cards and wrote their to-do items on each and posted them in their cube, I could walk by without saying a word.  I would know their status by way of a personal kanban.  

The idea worked.  People did a good job of keeping their work items up-to-date in columns for me to see when I came by.  But the thing was, they’d still want to *talk* about it. 

Then again, when they weren’t in their cubes, I could still see their progress.  Micromanaging, perhaps, but at least not as annoying.

That is, until the first snowstorm hit, literally. In late December 2008, we got a foot of snow, and ice to make it tricky to get to work.  Many people didn’t come in to work, including me.  We all could still work from home, but in a few hours, that personal index card kanban would be obsolete.

#FAIL, right?

Not really.  What I needed was something electronic, someone web-based.  Electronic, web-based index cards!  That’s it.  Then it hit me. 

Duh… another group I managed used ScrumWorks Pro to manage their workflow.  That’s what SWP basically is!  Why the hell wasn’t I using it on the project whose team I asked to use index cards on their cubes to report status?!?

When the weather got better and we got back to work, I went about telling my staff that I wanted to try a pilot project with SWP.  I wasn’t laying down a doctrine, just an idea.  Let’s try to get some ScrumWorks Pro licenses for a week and see how this thing shakes out.  Mythbuster Adam Savage is one of my heroes, known for saying “Failure is *always* an option” and I wanted to consider that.  Besides, better to allow a culture to integrate something new than to force that culture to adopt it.  History is full of lessons there.

But it worked.  The pilot program showed that people found value in it, so we extended it another week.  By week 3, it was part of our toolset.  People reported status by saying, “check the burndown in SWP” and they included screenshots in their status reports for me.

—–

Idea #3: There was a projector in one of the conference rooms that had a burned out bulb.  The thing was it couldn’t be removed because it was chained to the desk with a lock and no one knew the combination.  Not even the admin knew.  Still, another projector was brought in and the old one shoved aside as best as could be. 

This annoyed me.  Here was waste, just sitting here on the desk, a blaring reminder of bad form — someone forgot the combo and this thing would take weeks to be sorted out, if ever.  No one cared because no one thought anything could be done.  So during a slow meeting, I started hacking the lock.  It was only 4 digits.  I figured it might take me several long meetings in a row to run 9999 combinations, because I was testing about one per second.

Testing.  This was a testing problem!  What I was really doing was reproducing one bug, right?  The combination!  So the test/explorer in me kicked in.  What heuristics can I use?  The number of the conference room as the combination? The admin’s birthday? The number of our street address? Why try all 9999 when all I needed was a smart risk-based strategy?

But no, it wasn’t that easy. Even when getting others’ opinions on what the combo was, it didn’t budge.  But there I was, fiddling anyway.  I tried an OFAT test — One Factor At a Time. Instead of counting up, I started at 5555 and tried 5655, 5675, 5678, and drew a little diagram where I would use a V model, counting up then counting down in the 5000s by changing one number. 

At 5235, it popped open.

But even though I could describe my approach, and it worked, it was still heuristic.  It was still fallible.  Still, the important discovery I made, despite being flush with success (and a small celebrity for my accomplishment) I decided it was a worthy testing game. 

The next day, I came to work with a combination lock of 4 digits and invited my testers to try ideas to crack it, noting each of their ideas in a notebook for them so they could try things very quickly.  I was their log file, basically.  And it was fun, and revealing.  Everybody tried 0000, 1234, 1111, 2222, 3333, etc.  They seemed the easiest tests with the littlest cost of remembering.

To get clues, some asked me what my birthday was or what my cube # was.  That was fair game.  “Yep,” I said… “I thought of those too with the projector lock.”  But they also offered things I didn’t think of, like whether the combo was on a little slip of paper in the box it came in; comparing it to another new lock from the same rack at the same store; and determining the combination by feeling the way the tumblers rolled, listening with their ear to the lock for any clues as to what digits may be “looser” than others. 

The anchoring idea here was the creation of a portable tester game that sought to test critical thinking skills in a low pressure way.  The next day, someone brought in a 5-digit lock, but instead of numbers, the digits were letters, and you could program it to be anything you wanted, if you knew the secret trick.  Cool idea.

—–

Not all ideas might work — that is, not all will meet expectations to the degree you need them to.  But I find that many half-baked ideas are worth baking. They can lead to what my brother calls “learning cascades” — a series of discoveries made by following curiosities that lead you to the next big idea.

I’ll close with this:  My title at Quardev is “Manager for Corporate Intellect”. 

It was my idea.  I made it up. 

I knew that if we’re going to sell testing services, technical writing services, consulting, and training, that our success in these four categories would be based on the power of our ideas — our intellect. 

I bet the same is true for you.

For what it’s worth, I don’t think enough of us are talking about our half-baked ideas, especially our failed ones, so “Half-baked Ideas” has been the subject of my last few conference talks.

I look forward to hearing yours!

Advertisement