All Posts in Cognitive Enterprise

|In: Cognitive Enterprise|Last Updated:

Before there was Equifax there was British Petroleum. Before British Petroleum there was Enron.

All three were responsible for disasters. And, all three are evidence of something every who leader needs to embrace:

It’s always the culture.

Sure, skills and experience, tools and technologies, and processes and procedures matter too. For example: Just as you thought it couldn’t be any worse comes the revelation that in Equifax Argentina, an internal system that provided access to customer records had a backdoor, where both login ID and password were “admin.”

Proper security policies and procedures would have prevented this.

Just kidding.

For all I know Equifax Argentina’s security policies and procedures are just fine and dandy. If they’re out of step with the corporate culture they wouldn’t have made any difference. Culture wins every time.

Call it Lewis’s Law of Unnatural Disasters: When something goes terribly wrong you can bet there’s something about the organization’s culture that makes terribly wrong inevitable.

But in engineering your organization’s culture … and yes, culture is something to engineer … you need to consider your chosen solution’s ripple effects for the culture to be a positive force.

Let’s hypothesize that Equifax Argentina does have security P&Ps that specify what constitutes a suitably secure password — that the fault was a culture that resulted in nobody giving a damn. What cultural trait should its leadership be encouraging to prevent a recurrence?

The obvious one is a culture shaped so the employee handbook is law and everyone obeys it. That should do the trick.

It would. It would also create a culture where jailhouse lawyers are on a constant quest for loopholes that can only be closed by increasing the length of the P&Ps. Eventually, all your employees would need a year of study just to learn what’s in the handbook.

Beyond that, it would lead to a culture where checking off the boxes is what matters, not accomplishing the desired outcomes.

Worst of all it would result in a culture that combines blind obedience with a complete absence of risk-taking and initiative.

Compare that to a culture that focuses more on outcomes than obedience. Culture is loosely defined as “how we do things around here.” The cultural trait We don’t put people at risk” wouldn’t just eliminate the admin/admin login/password combo, whoever put it in place would suffer a fate worse than being fired.

They’d be shunned.

But there’s a complication in all of this that isn’t easily addressed.

Enron’s CEO and board chair, Jeffrey Skilling and Kenneth Lay pleaded the ignorance defense — yes, Enron the corporation was doing awful things, but they didn’t know about them. After Deepwater Horizon exploded, BP’s CEO Tony Hayward expressed a similar level of know nothing-ism.

Equifax’s executives haven’t yet pleaded ignorance, but it’s only a matter of time.

Which gets to the complication: They probably were ignorant, and in some important respects they should have been.

The best leaders don’t find ways to succeed. They build organizations that find ways to succeed. They can’t do this without delegating. They can’t do this unless the people they delegate to delegate.

In great organizations, employees at all levels have authority and take responsibility, to degrees that are surprising to those managers who consider any decision not made by themselves or someone higher up the chain of command to be an unacceptable risk.

Or as D. Michael Abrashoff, former Captain of the Benfold and author of “It’s Your Ship” put it, “I chose my line in the sand. Whenever the consequences of a decision had the potential to kill or injure someone, waste tax-payers’ money, or damage the ship, I had to be consulted. Sailors and more junior officers were encouraged to make decisions and take action so long as they stayed on the right side of that line.”

Sounds great. It is great. Only if someone on board the Benfold had done something reckless with Deepwater-Horizon-scale consequences, Captain Abrashoff very likely would have been ignorant, because that’s the whole point: The people in charge not making themselves decision bottlenecks.

Culture is certainly the first line of defense. But those pesky human beings being what they are, it isn’t a perfect, airtight solution.

Leaders also need metrics, controls, and governance mechanisms, to provide the guardrails that backstop culture’s lane markers.

But even with these, culture comes first because with the wrong culture, employees will find ways to jigger the metrics, fake out the controls, and game the governance.

What they won’t do without a culture that encourages it is take the risk of telling you something that should be happening isn’t, or that something that shouldn’t be happening is.

It’s always the culture.

Comments

|In: App Dev Methodologies|Last Updated:

It’s pop quiz time. The quiz has one question: Which application development methodology is gaining the most popularity?

If you answered “Agile,” Blaaaaaaat! Wrong answer bucko.

If you tried to demonstrate your more in-depth knowledge of the app dev landscape by answering “Scrum,” Blaaaaaaat! Nice try, but wrongo.

Test Driven Development (TDD) or one of its variants, Acceptance Test Driven Development (ATDD) or Behavior Driven Development (BDD), you’re just showing off. But Blaaaaaaat! TDD might be a technician’s paradise, and for that matter it might be a very good idea, but it isn’t what’s gaining the most acceptance.

Want one more guess? I’ll give you a hint: What do you get when you combine a change in process with the same old attitudes?

Now you’ve got it. The app dev methodology that’s sweeping the world is (drumroll) … Scrummerfall!

Scrummerfall (not an original term) is what you get when you stitch a Waterfall head onto a Scrum body. It’s what happens when you do want iteration and incrementalism, but for one reason or another want developers to do nothing but write code to specifications — you have no interest in their understanding the context, business purpose, or user predilections.

To be fair (an excruciating exercise but I’ll try) there are good reasons for going this route. In particular, if you’re willing to trade off Agile’s high levels of team engagement, enthusiasm and commitment for the large savings in raw labor rates you get from sending work offshore, Scrummerfall might be the right choice for you.

This is especially true in organizations that consider financial measures to be the only measures that matter, because from a purely financial perspective, it’s iteration and incrementalism that drain most of the risk from Waterfall’s combination of long-range planning and short-range planning accuracy. If all you do is wait as long as possible before making design decisions, that by itself will increase your project success rate.

What do you have to lose?

Quite a lot, as it happens. The problem is, what you lose by settling for Scrummerfall is much harder to quantify, because with Scrummerfall, what you keep is form but what you lose is essence.

Another way of saying it: Scrummerfall is an excellent example of what goes wrong when you mistake a business practice for a business processes. For the difference, see “Is it a Process, or just a process?” KJR 5/17/1999, although when I wrote it I used lowercase “process” where “practice” is now my preferred vocabulary.

In any event, with a true process, following the right steps in the right order gets you to the desired result. They’re repeatable and all that. The assembly line is your model.

That isn’t true with a practice. Following the right steps in the right order is just the ante that lets you play the game.

With a process, the steps are the essence. With a practice, they’re separate, and following the steps while losing the essence means the steps generally degenerate into nothing more than a bunch of check boxes people follow because they have to, not because they add any value to the proceedings.

And so to the differences between Agile and Scrummerfall. Start with the basics: Writing user stories and estimating them by assigning story points. (If you’re unfamiliar with these terms, user stories are the Agile equivalent of requirements; story points are vaguely equivalent to function points only they’re heuristic, not algorithmic.)

With Agile, the whole team writes the stories and assigns the story points, which means the whole team understands all of the requirements and commits to their estimated difficulty.

With Scrummerfall, business analysts write the stories and assign the story points. Team members only understand the user stories assigned to them for development, and instead of assigning story points … estimates of relative difficulty … the business analysts estimate the time that should be needed for development.

Anyone who’s been on either side of any exercise in delegation knows the difference between me telling you how much time you should need to achieve your assignment and the you telling me how much time you’ll need.

What’s the financial impact of the difference? We can envision what the research needed to answer a question like this might look like, but I certainly can’t imagine who might pay for the research, let alone any business leaders making decisions based on this research.

There’s one more piece of this puzzle to mention right now, and that’s the core model for The Cognitive Enterprise — that cognitive enterprises replace the old people/process/technology model with customers, communities, and capabilities.

With true Agile, developers and business stakeholders form a community.

With Scrummerfall, they’re just cogs in a machine.

Comments