All Posts by Bob Lewis

|In: Career Management|Last Updated:

Once upon a time there was a queen bee.

She enjoyed talking to her beekeeper, who, fortunately enough, enjoyed listening to her. She was fortunate, that is, because the beekeeper considered himself a poor conversationalist, and so was happy not to have to share the burden of finding interesting topics to talk about.

Queen Bee

And besides, there are lots of talking beekeepers around, but not so many talking bees, so he figured he’d take advantage of the opportunity while it lasted.

The beekeeper was in this way wise, but he wasn’t very bright. The evidence: The queen’s favorite topic was the land of milk and honey, and how she was going to lead the beekeeper there.

Finally the day came when the beekeeper couldn’t stand it anymore. “Let’s go!” he said to the queen, flushed with the enthusiasm that comes from a vision of a better tomorrow. “I don’t want to wait another day!”

So off they went to find the land of milk and honey.

Leaving behind a hive full of honey. And full of the worker bees who made the honey. Also all of the ingredients needed to make a new queen for the hive.

The moral of the story is, don’t be a queen bee CIO.

I ran across one of these characters not all that long ago. I had four one-hour conversations with him over the span of a couple of months. He was a visionary, talking in glowing terms about how the brilliant information technology he’d recently brought in and the new and even more brilliant information technology he was going to bring in soon that would transform the company.

Remarkably, in all of the time we spent together he never once mentioned anything about the department he “led,” what his plans for it were, where it needed to improve, or where it already excelled.

Unremarkably, nobody in the entire IT department could make a decision of any kind, with the possible exception of where to have lunch.

What causes an IT manager to become a queen bee? That’s for psychologists to diagnose, not workaday IT commentators. Or perhaps for budding ethologists. We could, I suppose, get them together to resurrect the pointless nature vs nurture debate, even though it was long ago resolved.

Bee it nature, nurture, or a combination of the two really doesn’t matter. A queen bee sits at the top of your IT hive, and you have to cope with her. Or him; unlike honey bee queens, both male and female CIOs can wear an apian crown.

So what you do if you report up to a queen bee CIO?

You could feed her/him royal jelly (pushing the metaphor to its limits, this of course means mastering the fine art of sucking up). This can work in the short term … queen bees do love hearing how brilliant they are … but it’s a bad habit to develop. Once this becomes your normal you’ll lose the habit of initiative and decisiveness that help you succeed in healthier environments.

And so you’ll find yourself seeking out queen bees to work for.

No thanks.

Then there’s the obvious solution: Leave. It’s the best general-purpose advice there is no matter which sort of bad manager you report to, because bad managers aren’t going to change — the attitudes and behavior that make them a bad manager are what, in their eyes, got them to where they are today.

So by all means, explore the world of opportunities that surrounds you.

But as you do, consider a different sort of departure.

As has been pointed out in this space from time to time, wise CIOs are starting to encourage what’s commonly called shadow IT — information technology that happens outside IT’s organizational boundaries.

Unwise CIOs still try to stomp it out, but fail.

Therein lies an opening you can exploit.

If there’s one thing you can be certain of, it’s that your corporate beekeepers will soon tire of the queen bee CIO’s tales of milk and honey. They want their milk and honey right now.

And if IT can’t deliver it, well, maybe shadow IT can.

With your help.

You will, of course, need to tread cautiously. But there’s a good chance your company has a director or three who have the budget and don’t care about obeying the IT governance process that’s been stymying them as they try to turn their own visions into business reality.

You know IT. You know the business (you do, don’t you?).

With finesse, you can be the person who actually does make IT happen.

Not a bad place to be when the CEO kicks the queen bee CIO out of the hive.

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