PERFECT example of bureaucracy vs. process

What is the world coming to?!  Two posts in a month?

Well, when life hands you perfectly fitted, hand-picked, juicy, gift-wrapped, actual too-good-not-to-share learning-rich examples on a silver platter... you've just gotta take 'em and share 'em!

One such example was handed to me a little while ago -- thanks to the US Department of State via the US Postal Service. 
No, the Postal Service didn't deliver something to me from the State Department.  It's more like the Post Office was the instrument of the State Department's bureaucracy.

A perfect duet of two bureaucracies operating in perfect bureaucratic harmony.  Though, when I think of "bureaucratic harmony" it sounds like an out-of-key dirge played in a decaying public school building by a poorly equipped elementary school ensemble.

But, enough of the musical analogies... We've got a bureaucracy to pick on and how and why my experience at the post office that week provided me such rich fodder for a blog post about processes.

This experience crystallized a way to teach the distinction between: Process, Procedure, and Bureaucracy.

So, the context of the lesson is in the State department's requirement to verify the parentage of minors (children under 16) applying for a US Passport.  To avoid issuing passports to minors (or in particular, to adults in the company of minors), the relationship between the minor and the adult must be established.  In a typical example, parents must demonstrate that they are, in fact, the children's parents.  When applying for a passport for a child, parents must show that (a) they and their children are US citizens and that (b) the children belong to them.  The State department requires that the children and both parents be present while applying and that the parents supply the child's birth certificate.  So far so good.

The lesson appeared when we were applying for a passport for a child for whom we already had a passport.  In other words, we'd already provided the necessary documentation to prove we are our child's parents when we first obtained the passport.  We appeared at the post office with an expired passport in hand and all the other documentation, except for the birth certificate (for the child who already had a passport, and thus we'd already proven our relationship).  Since we'd already provided the birth certificate in order to obtain the original passport, we figured the post office merely had to ensure that we were still who we said we were by looking at our government-issued ID (which is also required when applying).

Even if there was risk of someone else finding our child's passport and attempting to represent themselves as our child's parents, their IDs wouldn't match the names, and even if they did, in such a case whether or not they were *us* wouldn't matter.  Imposters with that level of sophistication could get anything they needed.  But, under normal circumstances, if someone else were to try to pass themselves off as us, their names wouldn't match up.   In other words, if adults show up claiming to be a child's parents, then their names should match that on the application and the child's documentation.  If the names don't match, then additional documentation would be appropriate, as in the case of adoption or other name-mismatching situations.

Anyone can buy a birth certificate, so, in fact, the longer we exist, the better the chances of identity theft.  Therefore, the earlier someone gets a passport, the more likely it was obtained with authentic data.  So again, the best "proof" that we are our child's parents is the fact that we had a prior passport along with the other documents.  However, the State department's bureaucratic procedures, dutifully executed by the Post Office, required that we present a birth certificate nonetheless.

At Entinex, we define a Process as the high-level depiction of a value-adding activity that produces an outcome.  Processes are the activities that are necessary for the product being worked on (or work being done) to achieve the outcome the customer of the work desires to have.  If the proper outcome is achieved, as long as the cost and schedule was within the customer's expectations, the customer ought not care how the outcome was achieved.  The process can be the same from context to context.  In fact, minimizing unique variants of a process in a given organization makes it easier to manage.  In our passport example, if the State department had issued a process rather than a procedure the process would simply be: Establish and Confirm parent and child's identity, relationship and citizenship.

The how of the process we define as a Procedure -- the specific steps needed by the process to produce an output.  There are likely many ways (i.e., many possible procedures) to accomplish the process' expectations.  Procedures are best applied to very particular contexts and ought to change from context to context.  From a value stream perspective, procedures actually consume value.  The intention of any organization ought to be to minimize the gravity of the procedure since if/when the procedure takes more time or resources, it costs more and therefore raises the cost of the process and often reduces its value.  Procedures are served best minimally.  Had the Post Office been allowed to create their own procedure(s) to accomplish the above process, they could have created procedures to check for artifacts that identity has been established/confirmed by means of some level of reasonableness.  The Post Office could have different procedures for first-time applications, subsequent applications, and name-mismatches.

However, instead, the State Department issued a procedure that was not context specific and wasteful.  It didn't give the Post Office (or anyone else) the flexibility to find the most appropriate way to determine identity or relationship, or to distinguish between the permutations of application situations.

In other words, the State Department established a bureaucracy:  A procedure in absence of context. 

Bureaucracies are often intended to compensate for lack of competence or trust, or as input to an over-engineered system.

Take your pick on this one.

These requirements "smell" and not because they're in a gym.

It's been said ad nauseam, to the point of being a "law" of engineering: writing requirements well is not easy.  The sign depicted here is in a hotel fitness room and is a clear example of just how true this is.  (Click on it for a larger, more readable image.)  Some requirements simply "smell" funny.

Agile doesn't "fix" this and neither does CMMI. 

What agile does, however, is provide several ideas on how to minimize the negative impact on the challenge of poorly written requirements.  Some of these ideas include close proximity of the customer and/or users, frequent iterations and demonstrations, only incremental value added between demonstrations as opposed to huge bounds between them.  These ideas, however, are their own practices, processes and procedures. 

What's in CMMI regarding requirements has more to do with eliciting them, decomposing them, thinking them through, validating them and then managing them.  What CMMI doesn't supply is anything about writing them well in the first place.  Before any CMMI experts argue this point, make it through the next two paragraphs.

Notice that agile doesn't either.  All agile does is mitigate the risks posed by poorly formed requirements.  While a few practices in CMMI can foster opportunities to catch poorly formed requirements, none of the practices in Requirements Development (RD) or Requirements Management (REQM) actually prevent an organization from writing them poorly in the first place. 

True that review of the work products of RD and REQM *could* uncover poorly written requirements but that assumes the organization has experts or standards capable of creating well-written requirements or catching when requirements aren't well-written.  An organization poor in the requirements expertise bench wouldn't glean much from CMMI by way of what "well written" means to that particular product, project, user or organization.

A good friend and colleague, Dale Emery has a few ideas on how to ferret out requirements that "smell".  While Dale's material dealt with "problems" that smell, I've adapted them to smelly requirements.  Whether they are buried in user stories or come to you in a BHB ("big honkin' binder"), here are a few of the "tests" you can run to determine whether your requirements "smell" or not:

• No user(s) identified for a feature.
• An identified user is not part of the system.
• A solution is embedded into the expectation that's not validated as a priority for the system.
• Exceptions are the rules.
• Exceptions are ignored because they're "rare".
• Written on non-validated needs.
• Unexpressed (unfunded?) pre-requisites.
• Any hint of emotion or blame.
• Uses terminology of what's not desired rather than what is.
• Assumes/asserts a priority (in a vacuum).
• Can't find an audience to care about what's in it.
• "Should", "Can", "Could", "Might", etc.
• Assigns responsibility to another part of the system.
• Any absolutes.  (Some are necessary, but all should be verified/tested.)

What makes the above sign smell?

Hint: it's not the sweat.