All Posts in App Dev Methodologies

|In: App Dev Methodologies|Last Updated:

News flash: business is speeding up.

Okay, maybe it isn’t news. But if it isn’t, why are so many businesses slowing down?

No, it isn’t your imagination. Read “The Hard Evidence: Business is Slowing Down,” Tom Monahan, Fortune, 1/28/2016). Among Monahan’s findings, using 2010 as a baseline:

  • IT project delivery has slowed, from 8.5 months to 10 months.
  • Open positions take longer to fill, from 42 days to 63 days.
  • Purchase decisions are taking 22% longer.

Like all statistics, these are open to alternative interpretations. IT Projects might, for example, have become bigger and more complex over the five years covered by the study.

Or maybe it’s due to Agile: Emptying a dynamically managed backlog might take more time than finishing waterfall projects that exercise tight scope management. Completion is one thing. Agile’s shorter time to first value is something else.

For hiring, with 2015’s lower unemployment rate, open positions might have become harder to fill. For purchasing … I’m sure we can come up with something if we put our minds to it.

Or not. Monahan’s data match my experience — the average business errs on the side of caution, never mind the impact on velocity and agility.

What if Amazon made decisions this way? Google?

A better question: What will you do if Amazon or Google decides to invade your markets?

This sort of invasion isn’t always apparent, either. For example, do you think the folks at Dex realized Google Maps was an invasion when it first appeared?

Truth in advertising: Neither did I, until I realized that’s where I was looking for nearby sellers of what I wanted to buy, leaving the Yellow Pages on my kitchen bookshelf.

But then, nobody was paying me to realize it, so I don’t feel all that bad about missing it.

Here’s a guarantee: If your business sells physical products, it’s at risk of invasion from competing products with embedded intelligence and connection to the Internet of Things. If you sell some form of services … see Google Maps, above.

Justifying delay until flank attacks appear by claiming a “fast follower” strategy is a losing proposition. Among the reasons: fast followers are rarely the companies that know how to be fast.

How does a business become fast? Getting rid of everything that makes it slow is a good place to begin. Start with decisions. These are things politically-driven business managers avoid like rabid weasels, by the way, so a business speed-up artist is operating in a target-rich environment.

And there’s no richer set of targets than the variety of governance and steering committees that pervade most enterprises.

Maybe you’ve avoided this infestation. But probably not. The bigger the decision, the more likely it will be governed by a committee, specifically to give decision-makers political cover should something go wrong.

Here are five straightforward steps for scaling back committee decision sclerosis:

  • Size: Committees generally make decisions by consensus. The difficulty of reaching consensus grows polynomially with the number of committee members: In round numbers a committee of ten takes three times as long to reach consensus as a committee of five.
  • Composition: Most committees are composed of representatives from different business constituencies. They’re included to protect their areas’ interests. Committees designed like this aren’t just a consequence of siloization — they’re an endorsement of it.

Populate your committees based on expertise instead.

  • Cadence: Most committees, most of the time, gravitate to a monthly meeting schedule. This make the month the standard unit of time for decision-making. Worse, it builds wait-for-the-next-meeting into the management culture.

Do something radical: Insist that all committees meet weekly instead. Don’t worry about this congesting the company. The effect can be the exact opposite: Committees that meet four times as often ought to have meetings that only last a quarter as long.

  • Culture: Make culture your new governance. Build the right decision habits into it, and culture can be your decision-making “lane markers.” Reserve formal governance committees for use as its guard rails.

Unless, that is, your company makes a habit of hiring and retaining employees and managers it can’t trust to make good decisions. If that’s the case, fix your staffing practices.

Then make culture your new governance.

  • Disband: Do you really need a committee to make this decision? Rely on individual stewards instead, requiring them to make decisions consultatively rather than by consensus or, at the other extreme, solely through their personal judgment and expertise.

There. That wasn’t so hard, was it? Sure, most members of most committees will run away screaming in terror.

But that’s a small price to pay.

Comments

|In: App Dev Methodologies|Last Updated:

Why have Agile methodologies (including DevOps, which adds agile deployment to Agile development) made such inroads in IT? Why is OODA (observe, orient, decide, act) so important for business strategists?

Agile/DevOps is OODA applied to application development; OODA depends on business agility, applying many of its core concepts to external threats and opportunities.

It starts with the gunnery problem. In case you aren’t familiar with it …

You’re shipboard. You man an anti-aircraft gun. The shells you fire have an initial muzzle velocity of around 2,500 feet per second, decelerating due to gravity as they ascend toward the aircraft you’re shooting at.

The aircraft is a bomber. It flies at something less than 1,000 feet per second. Being a math whiz you can project exactly where the bomber will be when your shell reaches its altitude, allowing you to aim at the exact spot in the bomber’s trajectory where your shell and the bomber would attempt to occupy the same space at the same time.

But, the bomber is piloted by someone who, all things considered, would prefer that their aircraft’s trajectory and that of your shell don’t intersect, and so they don’t just fly in a straight line.

In application development terms, by the time your shell reaches the target’s altitude, the requirements will have changed.

Why Agile? So IT can deliver the software needed to support business changes (where you aim) in time for the planned change to still be relevant to the business’s new situation (before changes in the bomber’s flight path make your aim wrong).

Why OODA? Same answer: The attacking plane is a competitor, or the overall marketplace, or some important change in circumstances that will affect your business.

Your planned actions have to still be relevant when they “reach the attacker’s altitude” … when the changes you anticipate become real, recognizing that the more time that elapses the less predictable the future (the bomber’s position) is.

See, there’s a reason we’ve settled on the term “Agile” instead of “Fast,” which is that depending on what you mean by “fast,” waterfall is much faster than Agile, as was pointed out a few months ago in this space. It’s faster in that, assuming you have a useful way to measure software functionality, waterfall generally delivers more of it in a unit of time than Agile or DevOps.

But, waterfall delivers it all at the end of a long trajectory, during which business circumstances might change and change again. Waterfall design and development have a lot in common with a gunner shooting a slow, heavy shell that packs a lot of explosives at the spot a bomber would be in were it to continue flying in a straight line.

It’s a big bang that misses the target: Waterfall’s fixed requirements and specifications and need to develop and deliver the whole system in one piece conspire to deliver results that are largely irrelevant when delivered.

Pushing the analogy to the limits, Agile, and even more so DevOps, is less like a shell than a surface-to-air missile. They’re able to track changes to the target’s trajectory and adjust course accordingly.

Waterfall still has its adherents. Their near-universal explanation of waterfall’s high failure rate is that business people “don’t know what they want,” which presupposes there’s a way for them to know the answer to the question, “What do you want the software to do?”

Someone once studied people who design and build their own houses. Turns out, they’re rarely satisfied with the first one they live in. Generally, they aren’t satisfied with their second try, either.

If it takes three tries to design the house you want, keeping in mind that living in a house isn’t exactly terra incognita for most people, expecting a business manager to know in advance exactly how a piece of software should behave is several percentage points less than realistic.

And that’s starting with the false assumption that “What do you want the software to do?” is the right question to ask. It isn’t. A far better question is, “How do you want to run your part of the business differently and better?”

Even when IT asks the right question, the fundamental difference between the past and the future still intervenes. Presumably you know what this difference is: You can, in principle, get a pretty good handle on what’s already happened.

The future isn’t like that.

Comments