Organizational Effectiveness – Page 71

Is Agile really faster than waterfall?

As everyone knows, when compared to waterfall application development, Agile speeds things up, and DevOps speeds them up even more.

There’s just one little gap in what everyone knows: exactly what these things are that Agile speeds up.

When it comes to optimizing business processes and practices, speed has two very different and independent meanings — cycle time, which is the time that elapses between an average item entering the function as an input and the time it exits as an output, and throughput, which tallies how many completed items exit the function in a given unit of time.

For application development, I’m guessing most businesses care more about cycle time than throughput, but that’s just a guess. I’ve never seen any survey data to confirm it.

On the other hand, managers who want something from IT mostly ask and then gripe about is when they’ll get it. They care about cycle time and want it to be small.

So for the sake of argument, accept that the goal of supplanting waterfall development with Agile is to improve cycle time.

But as cycle time measures the time that elapses between something entering a function and exiting it, we’re back to the question of what are these things of which we speak?

Back in the days when waterfall held sway, the closest anyone came to nailing this down was the function point. Function points were (and are — the discipline still has adherents) supposed to correspond to business functionality, and so they do, in the sense of corresponding to software functionality business people use.

So we could ask the musical question, do Agile methodologies speed up the delivery of function points?

And we’d have our answer, which is the same as the answer to the question, “What’s the difference between ignorance and apathy?” which is, “I don’t know and I don’t care.”

That’s because Agile methodologies don’t deliver function points. They deliver user stories, each of which is assigned a degree-of-difficulty weighting factor, typically the aforementioned story points.

So on the subject of velocity we now find ourselves asking which delivers a user story more quickly — waterfall or Agile. But as waterfall deals in function points, not user stories, aren’t we still stuck with incomparables?

Well, yes, but not insurmountably, because a user story is, if you squint a bit and don’t worry overmuch about the details, pretty close to what in waterfall terms we’d call a requirement.

Al fin, nous arrivons! as a Parisian shopkeeper said to me many years ago as I was attempting, in my very limited French, to explain what I needed and he was attempting to make sense of my near gibberish.

At last, we’ve arrived: To compare the speed of waterfall and Agile, “all” we need to do is compare how much time elapses between the first articulation of an average requirement and its appearing in production some time later.

Interestingly enough, Agile doesn’t measure this. It measures throughput — story points delivered per week, or some similar metric. Why? Probably because throughput is what’s easy to measure never mind what matters most.

Superficially, cycle time doesn’t seem hard to measure. Except that with waterfall methodologies the early steps aren’t atomic: Business Analysts talk with a bunch of people (ConsultantSpeak: Stakeholders and subject matter experts), try to make sense of it all, and write up the result in a requirements document.

Average cycle time for this step: Total step duration (first interview through requirements publication and ratification) divided by the number of requirements described in the document, weighting each requirement by its degree of difficulty.

Agile equivalent: Time needed to rephrase someone’s requirement as a user story and add it to the backlog.

This isn’t an entirely fair comparison, though: Waterfall business analysts are expected to filter out low-value requirements. With Agile, they just sit in the backlog, never important enough to be worked on, either forever or until someone decides it’s time to clear all the dead items out of the backlog.

Which means with Agile, cycle time will have to be, shall we say, dynamically recalibrated from time to time to remove Worthless Items Never Worked On from the calculation.

Clearly, app dev cycle time measurement isn’t for the faint of heart. And we haven’t even begun to explore how to account for project failures.

Given the Standish Group’s current statistics — that Agile projects enjoy roughly three times the success rate of waterfall projects — accounting for this is an important piece of the puzzle.

The Mergers and Acquisitions Bunch

For employees, a merger or acquisition is a lot like The Brady Bunch:

In The Brady Bunch, the kids had to get used to a new parent having authority. In a merger or acquisition, managers from the other company now have authority.

In The Brady Bunch, kids who didn’t used to be brothers and sisters were suddenly siblings. In a merger or acquisition, people who used to be competitors are now fellow employees.

Every household has its ways of doing things. In The Brady Bunch everyone had to figure out the ways of doing things for the new, combined household. In a merger or acquisition, the unwritten rules of how things get done around here aren’t the unwritten rules any more. Or else they are, but just for employees of one of the two companies involved.

In The Brady Bunch, a laugh track told everyone what was supposed to be funny, even when it wasn’t. In a merger or acquisition, employees are supposed to pretend everything is great even when it isn’t.

Okay, it’s a reach. You try coming up with a brilliant lead every week. It’s a lot like having to write a new sitcom script … oh, never mind.

When it comes to mergers and acquisitions, the easiest approach is to operate a holding company, as was mentioned last week. In the extreme case this looks a lot like a mutual fund: The parent company owns a portfolio of businesses, which it mostly leaves alone.

Warren Buffet’s Berkshire Hathaway operates like this. It works. It just isn’t very interesting. In Brady terms, it’s sort of like the backstory of when Mike Brady and Carol Tyler were dating — the Bradys and Tylers were separate households, with all that implies (or implied in the late 1960s and early ’70s).

So let’s skip that part and go to the sort of merger or acquisition that serves a strategic, competitive purpose — one that fills out a product line, provides access to a new set of customers, adds production capacity … that sort of thing. What factors, beyond the usual textbook stuff, determine the success or failure of this sort of merger or acquisition?

One of the most important is both the easiest to understand and the hardest to accomplish: Changing what “we” means. Interestingly enough, the better-led the pre-M&A company, the harder this is.

In companies with excellent leadership, employees feel a strong sense of attachment to their employer. They have an equally strong sense that they personally own the company’s brand, defined as the expectation customers have regarding what it’s like to do business with the company in question.

Imagine a fine company like this … being brand mavens we’ll give it the snappy name Tyler, Inc. … is acquired by the marketplace behemoth The Brady Company.

Brady being what it is, and this being an acquisition, the combined businesses will retain the Brady monicker. Think Tyler’s employees will celebrate their new corporate affiliation?

Of course not. Their loyalty is to the Tyler brand. They identify with it. They live it. And it isn’t the same brand that Brady has — a difference that goes well beyond the name change.

See, Tyler prided itself in the tailored, customized service it gave all of its customers. It encouraged its employees to innovate — to improvise if that’s what made the most sense, so long as the result was something the customer in question would value, and so long as it was profitable, too.

That was the essence of Tyler’s brand, and its customers were happy to pay a premium price for the they-take-great-care-of-me sense of security that went with it.

Brady, in contrast, is all about finely tuned, highly efficient processes built to support standardized products and services. It also encourages employees to innovate — it has an Innovation Committee, in fact, to which its employees are encouraged to submit their ideas, which the IC screens, assesses, ranks, and prioritizes in its quarterly Innovation Planning Meetings.

Think the Tylers will all be happy about becoming Bradys? Of course not.

The sad thing about our mythical scenario is that Brady’s executives acquired Tyler specifically to gain its ability to provide premium service to its customers. What they haven’t done is figure out how exactly they’re going to accomplish this within their signature high-efficiency, product/service standardization practices.

And it gets worse as we look beyond the executive suite, because with increasing distance from the whole point of the acquisition comes an entirely natural attitude:

“We bought them, so of course they have to adapt to our way of doing things.”

* * *

In case you have a suspicious nature and think I’m writing about Dell’s coming acquisition of EMC, or NTT DATA’s coming acquisition of Dell Services, nothing could be further from the truth.

Among the reasons: I have no involvement in the former and as far as the latter is concerned I’m just a passenger on that train — I don’t know anything more about either transaction than you do.