Socratic Questioning

After reading the book The Goal: A Process of Ongoing Improvement by Eliyahu Goldratt, I found myself wanting to learn more about two things.  One, something known as the theory of constraints (TOC).  Two, the Socratic method or using Socratic questioning.  I'll leave TOC for another post.  This time around, I'll focus on Socratic questioning.  I started asking my client's vendor a series of Socratic questions, with some surprising results.   But first, what is Socratic Questioning?  From our old friend Wikipedia:

Socratic questioning is disciplined questioning that can be used to pursue thought in many directions and for many purposes, including: to explore complex ideas, to get to the truth of things, to open up issues and problems, to uncover assumptions, to analyze concepts, to distinguish what we know from what we don't know, and to follow out logical implications of thought.

The key to distinguishing Socratic questioning from questioning per se is that Socratic questioning is systematic, disciplined, and deep, and usually focuses on foundational concepts, principles, theories, issues, or problems.

Using my client's vendor as a guinea pig, I decided to give this a go.  Rather than just accepting what appeared to be a half-baked answers, I started to ask more of the same questions.

I asked questions like

• What do you mean by that?
• Could you help me understand this a little more?
• Is this always the case?
• Why do you think that this assumption is true in this case?
• Why do you say that?
• What is there reason to doubt the supporting data?
• What is the counter argument for this?
• What is another way of looking at this?
• But if that happened, what else would happen?
• How does this affect that?

Though I've always asked a lot of questions, I've never tried to be so systematic or disciplined in the process.  I'm frustrating the hell out of the vendor with all of the open ended questions.  But I think the client is getting better answers.  I hate to see someone ask a complicated question, only to get a yes or no answer.  I want to understand why someone is doing what they are doing.  Hopefully, by asking these types questions, the vendor will start to wonder why as well.

Have you used Socratic questioning before?  What was your outcome?

Book link to Amazon is an affiliate link. Original Drawing by Pictofigo

GLSEC Retrospective

I'm back from a quick trip to Michigan.  The Great Lakes Software Excellence Conference was taking place and my talk had been accepted.  My talk was titled Breaking the Law of Bureaucracy (I'll upload my deck in a few days) and the topic was Servant-Leadership.  Though I really enjoyed giving my talk, the best part of my visit was all of the people I interacted with.  I finally met Casey DuBois, a guy I've known via email and phone for over a decade.  We used to do business together (long distance) and this meetup was a long time coming.  Next, I met several people from Atomic Object and drank a bunch of their coffee.  Later, I met the organizers, sponsors, and other speakers who made the conference happen.  And to think that was just Friday. Saturday went by way too fast.  Everything ran very smoothly. I gave my talk, we played Simon Says and Red Light Green Light, and I even had an opportunity to meet Ben Lichtenwalner from ModernServantLeader.com. If I could have done anything more, it would have been attend more of the sessions.  The speakers and content were top notch.

It was really exciting to talk to a few local startups from the Grand Rapids area and to hear about a local incubator called Momentum. It made me realize the importance of local incubators and helping startups succeed.  These startups have solid ideas!  I'd write about them now but I want to have standalone posts for them.

So, I'm going to keep this short.

Thank you to Grand Rapids for a truly awesome experience.  A very special thank you to Mr. Casey DuBois for his amazing hospitality.

Judging an Agile Book

I'm in Grand Rapids, Michigan, to speak at the Great Lakes Software Excellence Conference.  If you ever imagined what an "Agile" company looked like, I think I am looking at it right now.  I'm blogging today from Atomic Object.  The exterior of the 100 year-old building is very unassuming.  Upon entering the building, I'm greeted by several dogs.  Yes, like in man's-best-friend dogs.  They give me the once-over and allowed me to pass.  I walk past a wall with mountain bikes and walk upstairs to discover a truly Agile workspace.

The floors are a light wood and the workspace is wide open.  There is plenty of natural light.  In the middle of the room is a functioning stop light.  It's exactly what I thought it was.  It's an information radiator to indicate if the build is broken or not.  Fortunately, the light is green.  I'm now sipping on a freshly brewed cup of black coffee and enjoying web access.  There are almost as many whiteboards as there are approachable friendly people.

I know you should not judge a book by its cover.  But, if I'm looking for a book on Agile, I would have a few expectations.  This place and the people working here exceed those expectations.

When I return to Washington DC tomorrow night, I'll take with me the first hand confirmation that Agile workspaces (and companies) are so much more inviting than those with cube farms or offices.

Zero Cost Effect

I had dinner with a colleague the other night.  I inadvertently quoted something verbatim from Dan Pink's book, Drive. My colleague said if I liked Dan Pink's work, I should read something from Dan Ariely.  So, I started on Predictably Irrational:  The Hidden Forces That Shape Our Decisions. Wow, this book is crazy!  I'm not going to go into any more details in the post other than a comparison of an experiment detailed in the book and something I've seen in the real world. In the book, the author described an experiment on 34 Halloween trick-or-treaters. As soon as the children knocked on the door, they received 3 Hershey's (each weighing about 0.16 oz.) and were asked to hold the Hershey’s they had just received in their open hand in front of them. Each child was then offered a choice between a small (1 oz.) and a large (2 oz.) Snickers bar, under a Cost Condition and under a Free Condition.  In the Free Condition, they could simply get the small 1 oz. Snickers bar (for free) without giving up anything or they could exchange 1 of their 3 Hershey's for the 1 large Snickers bar.  In the Cost Condition, the children could exchange 1 of their .16 oz. Hershey's for the small (1 oz.) Snickers bar or exchange 2 Hersheys for the large (2 oz.) Snickers bar.  They could also choose to do nothing but all of the kids chose to make an exchange.

Experiment Results

In the Free Condition, in which the small Snickers bar is free, demand for it increases substantially (relative to the Cost Condition).  The results demonstrate the attractiveness of zero cost.  People gravitate more toward options that do not require giving up anything.

Example of this on a project

At work, I've had a Product Owner (PO) who wanted to add items from the Backlog to the Sprint.  During sprint planning, the team basically added a buffer, to account for unforeseen events.  I know people are going to crucify me for this, but basically, the Product Owner always seemed to want to shift priorities of work mid-Sprint.  Rather than killing the Sprint, we added a buffer.  This would allow new work to be entertained without totally derailing the work already being completed.  Yes, we could have used Kanban and all of this could have been avoided.  But, Kanban wasn't an option.

So, what happened?  I offered the PO a deal.  I could allow him to add a certain amount of work to the Sprint for free. When I did this, he usually asked for smaller deliverables (relative to other items on the backlog that were ready to work).  But, when I said some work would have to come off the table to pay for the new work, he always went big.  He would choose larger deliverables relative to other items on the backlog that were ready to work.

All I can say is we truly are predictably irrational.

---

Yes, the links to the books are affiliate links.

Relying on Indicators

I just realized I've been driving automobiles for 25 years. Do the math and I'm either older than you thought or I started driving earlier than you thought. Either way, I may have surprised you. What surprised me, the other day, was my reaction to an illuminated indicator light on my relatively new vehicle. It used to be, vehicles had very view indicators.  Of course, there was the analog fuel gauge.  I knew how accurate it was by the amount of times I ran out of gas.  There was also the check engine light.  I think I saw a check engine light once, back in 1986, when I simultaneously saw smoke appearing from under the hood of my 1980 Honda GLC.  My point is, back in the day, by the time you saw the indicator light, it was too late.  Fast forward to today and I realize I have half a dozen indicator lights and I'm very aware of them.

	Seat Belt: This indicator normally lights up if I have not buckled my seat belt.  The light is accompanied by a soothing reminder tone.  The result is I usually look around to notice if anyone is looking at me.  I sheepishly click my seat belt and go on about my business.  It happens on rare occasion, much like farting in public.  Either way, it's embarrassing and hopefully nobody is around when it happens.
	Low Fuel: This warning normally indicates the car is low on fuel and I should get to the nearest gas station. Fortunately, I also have a digital indicator that tells me how many miles I have left. Regardless of knowing how many miles I have left, having the light appear still creates a certain level of anxiety.  I guess it's merely a flashback from my reckless youth when I never seemed to put more than $5 worth of gas in my car at a time.  The difference is that used to get me more than 5 gallons of gas, compared to about one gallon now.
	Check Engine: This indicator still frustrates me.  I've seen this indicator a few times in the last few years.  Each time it was when the car was dead and would not start.  It would be nice if it actually gave me some kind of warning.  I know the car is dead.  If anything, it should be a scull and crossbones.  I'm not a car mechanic.  Therefore, what good does it do to tell me to check the engine?
	Tire Pressure:As a result of the Check Engine indicator light, I now have a new car.  It's full of all kinds of awesome things, like USB, Bluetooth, and a thermometer that tells me how hot or cold it is outside.  But, I have a new indicator light that I've never seen before.  Well, not before last week.  It's a tire pressure monitoring sensors (TPMS) to monitor the air pressure in each of the tires.

So, here I am writing a post about my car and the indicator lights. What's my point? My point is, the tire pressure indicator illuminated and I nearly got into an accident, trying to get out of traffic and onto the shoulder of the road.  I was suddenly concerned about what was wrong.  I didn't hear an explosion.  The car was not pulling to the left or to the right.   My gut was telling me that everything was fine but I've been conditioned into believing these indicator lights.  I got out of my car and looked at the tires.  All looked fine.  I took the car to the dealer and had them check the pressure.  All was fine.  After a diagnostic test, it was discovered that the sensor was malfunctioning.

Again, what's my point?  Do you use metrics or indicators on your project that tell you how things are progressing?  Do you think you rely on them too heavily?  Could it be you need to trust your gut more and the indicators less?  Next time you're measuring your team or project performance against an indicator (or metric), take a moment to kick the proverbial tires.  Don't just accept the metric as the truth, the whole truth, and nothing but the truth.

Now if only I could get that guy in front of me to notice he's had his blinker on the last 15 miles.

Smoke Detector Battery Replacement Process

smokedetector

Why am I writing about replacing smoke detector batteries?  It's all about process improvement. Every six months, we are tormented by our home smoke detectors chirping after we replace the batteries.  As a rule, we know we're supposed to replace smoke detector batteries at daylight savings time (twice a year). Also, if the smoke detectors start chirping or beeping off and on, we know it's time to change the batteries.  Six months ago, I decided I was going to put an end to the chirping once and for all.  I planned to document the battery replacement process and find out how to consistently replace the batteries with no chirping.  I created a decision table to help me get it all out on paper.  I then spent a few hours writing test procedures and testing the outcomes.  If you want to drive yourself a little crazy, listen to smoke detectors screaming in your ear for a few hours.  After all was said and done, I had a successful process documented.

You may ask yourself why I didn't check Yahoo Answers or eHow for the answer to my problem.  Well, I did and they sucked!

I searched on: Smoke Detector Battery Replacement Process, How to Change the Batteries in Your Smoke Detector Chirping Smoke Detectors Stop Chirping Smoke Detectors...

So, if the planets align and there is some poor sucker out there suffering from the same problem, I hope you find this post and it works for you.

Scenario:  We live in a three level home.  Each of the smoke detectors is wired into a single circuit and they all use 9volt batteries.  We are using standard First Alert smoke detectors.  In the past, if we replaced any or all batteries, the smoke detectors would chirp randomly.

How to avoid the annoying smoke detector beeping

1. Replace the battery and make sure the + and - are facing the correct direction.

2. One smoke detector at a time, replace the battery, connect the electrical plug, then push the test button.

3. Let the detector cycle through the screaming load test.

4. If there is more than one detector, move on to the next.

What was the problem?

The problem I was running into was the hush button.  The detector was so loud, I would push the hush button before it was allowed to run it's test cycle.  I included the action on my decision table and was able to isolate the problem there.

Just in case, in the event I forgot the process, I saved it in Evernote.  I just replaced all of the batteries and it worked perfectly.  I was so excited, I just had to blog about it.

My Own Agile Game

Because I will be speaking at the Great Lakes Software Excellence Conference (#glsec) on April 16, I will be unable to attend Agile Games 2011 (#agilegames).  Realizing my session was for 50 minutes, I wanted to include a game as part of my talk.  Seriously, can you image listening to me talk for 50 minutes straight?  When I've seen other speakers who included collaborative play or human interaction in their presentations, it made the session so much more enjoyable.  So, I contacted Brian Bozzuto of BigVisible to ask if he could help me with a game on servant-leadership.

Brian made some recommendations and here is my final idea.  I call it Simon Says versus Red-Light-Green-Light. I'll admit, I find it hard to believe someone else has not documented this "game versus game" as an exercise to help people understand the concept of empowerment or servant-leadership.  If you know of someone who has documented this game, please let me know so I can give them credit.

Command and Control Management

Game: Simon Says (Modified) The Goal: Participants want to get from one side of the room to the next, via instructions from you (Simon).  Participant must be navigated around obstructions and follow Simon's instructions (regardless if instructions help the participant get closer to the goal or not.)

1. Line up a group across the room from you.
2. Tell the players that they should all obey you if you first say the words "Simon says." (all directions will begin with "Simon says")
3. Tell them the goal of the game is to get across the room in the shortest possible path.
4. Begin by saying something like, "Simon says, participant 1, take 3 steps forward."
5. Look to make sure he or she has taken 3 steps forward.
6. Give another order such as, "Simon says, participant 2, take 1 step to the left."
7. Continue giving orders. Having the players navigate toward the goal and around obstructions.
8. Give a few players direct paths to the goal and a few players crazy instructions that do not help them reach the goal.

Servant-Leadership

Game: Red Light Green Light (Modified) The Goal: Participants (cars) want to get from one side of the room to the next, via self-direction and verbal input.  You will act as the stoplight. Someone will act as the obstructionist, who will block cars with whatever is available.  When stopped, the obstructionist will block cars.  The stoplight will then ask the cars if they want obstructions removed or if they want to continue on.

1. Line up a group across the room from you (the Stoplight).
2. Tell the cars that they should all obey the instructions to stop or go by the verbal queues of red light and green light.
3. Tell them the goal of the game is to get across the room in the shortest possible path.
4. Begin by saying "Green light", allowing cars to approach the goal.
5. Give the order "Red light."
6. Have an obstructionist block the cars in some way.
7. Ask the cars if they wish you to move any obstructions or if they wish to continue on. (just ask if they need help)
8. Give stop-go orders until the the last car reaches the goal.

That's it!  That's my comparison between a traditional top-down management environment versus an empowered environment with the assistance of a servant-leader.  If you have any comments or suggestions, I would love to hear them.

HT: Brian Bozzuto

Getting PMI Agile PDUs Early

Let's say you're interested in the upcoming Agile Project Professional (APP) certification from PMI.  You look to see the eligibility requirements and notice you'll need 21 hours of Agile Project Management Training.  If you're determined to get the PMI APP and looking to do this on the cheap, start watching webinars now. I can guarantee there will be a lot of training opportunities in the near future.  Check out a future location to find upcoming Agile PDUs. Once it is fully rolled out, it should be an excellent resource to find PDUs to meet your PMI needs. So back to the intent of getting the training.  After I read (and recently reread) Dan Pink’s book, Drive: The Surprising Truth About What Motivates Us, it made me stop and question why people wanted to get the PMP or APP.  Are we trying to discover better ways to deliver value to customers or just trying to get a piece of paper and a few extra letters after our names?  Dan breaks it down to pursuing the mastery of performance-based objectives versus learning-based objectives (ie. getting a passing score on a certification exam versus learning new approaches to deliver value to customers).

Regardless, information is information and I want to do what I can to help people discover it.

One of the approaches I really enjoy using is Kanban.  Today I stumbled upon a free Kanban webinar.  Though you do have to enter some contact information, it's free.  You have the option of downloading it or viewing a playback.  So, regardless if you're looking to bank those PMI Agile PDUs or not, enjoy 1 free hour of training.  By the way, I am in no way affiliated with the provider.   I just like free webinars.

HT: ASPE Events HT: Agile PDUs

Link to Drive is an Amazon affiliate link Drawing by Pictofigo