Seat-backs and tray-tables . . .

A few weeks ago, I blogged about a frustrating incident in an organization created a bureaucratic procedural approach to achieve the desired policy outcome rather than to create a process that would empower the people performing the activity to ensure that the policy was met in the most efficient manner.

That post caused a series of interactions with someone who took issue with my post and assumed the position to defend the procedure I was annoyed with.  I believe we left the matter at a point of agreeing to disagree.

Perhaps this post will cause a different group to take issue with me, but many more people are likely to relate to the content so I can convey the topic of policy-process-procedure in a different way.

A few days ago I found myself in an airline row with 3 seats to myself from the aisle to the window.  As a frequent flyer I automatically ensure that my seat-back is forward and my tray-table is "in its upright and locked position" at all the expected points in the flight profile.  But this time, when it came to landing, it got me thinking (again) about the policy-to-procedure "food chain".  Something seemed a bit over-kill-ish and I wasn't sure at first why.

In particular I was ruminating on the requirement to put your tray-tables up and bring your seats backs forward during ground operations, take-off and landing.  Why?

So I started with the question: what could this requirement be fulfilling?

That's easy: Safety!

But then: what is it about safety that this specific requirement fulfills?

That's easy too: Avoiding injury in case of getting tossed about in the cabin plus the need for people to be able to get out of the plane in case of emergency.

OK.  But still: what's going on that would lead to someone getting injured and/or being impeded from getting out of the plane in an emergency?

And that is when I realized what's going on.

The requirement to put our seat-backs forward and our tray-tables up *is* over-kill in certain situations.  Well, the tray-tables part really is NEVER over-kill.  That's *always* a good idea.  But, specifically, I was thinking about the seat-backs part as sometimes over-kill.

Like in the situation I found myself in.

Airlines have to comply with the FAA's regulations and create their own policies to do so.  In fairness, I have not read the FAA's regulation on this, but since I am learning to fly, I'm generally familiar with the way in which flight regulations go.  Where it concerns passengers, the regulation is about safety, and it isn't up to the FAA to tell airlines exactly how to make that happen.  Airlines don't have to give you seats that recline, or tray tables to put your things onto.

So the airlines come up with policies to ensure they comply with the regulations.  And, then the airlines come up with processes to execute the policies and procedures to perform the processes.  Or, often, they just skip the process part and jump right into procedures.

You see, bringing up our seat-backs is a procedure intended to ensure a policy (and a regulation) is fulfilled.  But the policy (and the regulation) can be fulfilled in other ways.  Yet the airlines don't provide flight crews with any other way and as a result, passengers are (sometimes) inconvenienced. 

Had the airlines created processes instead of procedures, then bringing up our seat-backs would be a function of whether or not anyone would actually be impeded by having our seat-backs reclined.  In the situation a few mornings ago, not only did I have an entire (half) row to myself, but the half row behind me was empty.  With no one next to me, no one behind me and an exit row several rows away, I could have left my seat all-the-way back and not bothered anyone's attempt to get out of the plane in an emergency, I could have rested more comfortably during landing, and I wouldn't have wasted a flight attendant's time asking me to put my seat up (which didn't happen since I did it anyway -- but I'm just sayin').

However, I'm not about to advocate for a change to airline policy on this point.  Really, there are many other factors to consider, and six seats with only one passenger in them isn't common anymore so the likelihood of not needing to put-up our set-backs is rare.  The procedure is nearly 100% appropriate and for the less than 1% of instances where a better process would have helped, it's entirely NOT worth it.  I'll suffer.

In all honesty it wasn't a big deal at all.  In fact the observation was merely mental gymnastics for me, but it did serve as good fodder to help explain the difference between policy, process, and procedure.

Amazing Parallels

A recent post to the Agile Thoughts blog caused me to have a serious case of déjà vu. 

First, I will start by saying that I'm not going to take a position on the content of the post.  Namely, I'm not going to weigh in on whether or not Scrum is valid, whether or not Mary Poppendieck's points or approach are appropriate.

The purpose of this post is to make a suggestion.

Go ahead and (re)read that post. 

Replace

• "Scrum" with "CMMI",
• "CSM" or "Scrum Master" with "Lead Appraiser", and
• "Lean" with "Agile". 

My favorite line in the entire post is this one:

"... spent 90% of her time cleaning up after bad Scrum implementations..."

And an associated comment that noted:

"...the difference between the good and the bad ones depends mainly on who’s doing it..."

I don't feel like taking the time right now to ponder what it means (I'll probably do it anyway after posting), but what I find fascinating is that people are now debating various agile/lean concepts in the way the debate continues to fester about CMMI/agile.  And, those in the agile/lean debate are recognizing that it's not enough to have a named method or model, and it's not enough to be "certified" to do something to really "get it", but that there is real need for understanding the underlying concepts and intentions and for implementing from that basis otherwise there is risk of "bad implementations".

What every perspective in these discussions is (hopefully) saying is that there is no one "silver bullet".  That addressing the issue of great products, ecstatic customers and happy teams requires more than superficial application of someone else's ideas.  Requires more than one set of principles, when hiring an "expert" requires serious due diligence and interviewing skills, and requires a lot of hard work and soul-searching to reach the "comfort zone" of every project and team.

Again, I'm not pointing fingers and I don't want to accuse one person of saying something they're not, nor do I want to label an entire field of people with any one person's perspective.  With that said, the following is drawn from my own experience and I'm merely reminded of it thanks to Tobias Mayer's post.

Many people now finding themselves defending Scrum -- against bad implementations and other abuses -- are saying that it's not anything inherent in Scrum that's bad.  My guess is that many of these people are (or were) also among those who vilify (vilified?) CMMI.  Accusing CMMI of evils that were perpetrated by too many goobers inappropriately implementing and appraising it.  Vilifying CMMI (can be read: Scrum) by juxtaposing implementation with content.  These evils are just as much not CMMI's "fault" as bad Scrum implementations are Scrum's "fault".

In fact, our recent SEI Technical Note, spoke to this very issue.  I guess the point to this post is to say to those folks in the Scrum and Lean communities: Welcome Aboard!  Let's start some constructive discussion together on defeating "silver-bullet-ism" in software development.