1. Agile focuses on product to build fast and decrease cost of change.
2. Agile management principles can be transferred to corporate management.
3. Corporates are facing an existential threat from technology and must learn execute in tech to compete.
4. Agile corporate structures allow you to focus on outcomes, design late, respond fast,  and decrease the cost of change.
5. This is increasingly indespensible to execute efficiently, compete fast and avoid disruption.

The idea of agile management in IT being of relevance in the corporate world has been around for a long time. Some of us nerds who dabble in both realms have expressed the founding principles of agile in more corporate speak, but essentially the idea of getting teams encapsulating the expertise required to create solutions for customers quickly is a no brainer. After all that’s broadly how companies like to organise themselves.

In agile, our plans carry technical debt. Whenever we choose to code at pace we intentionally trade off either features, quality or compatibility against perceived future need, against cost, against capacity and against time.

However we also often inadvertently trade off future usability by just not thinking clearly about, well, the future.

This is technical debt. Most agile managers will log technical debt as best they can, so they can plan out where clients can and can’t go with what they’ve got over and above the simple feature list or roadmap.

The important thing here is perceived future need, and whilst there is huge overlap with a roadmap or spec sheet this isn’t the same thing.

It’s about thinking about your architecture, users and hardware and what the future holds for them.

Technical debt is where poor decisions somehow shut the new doors that you could have opened. Where your failure to think about the future means your work needs re-doing as opposed to a tweek, and it’s where you can be disrupted.

So again, the purpose of agile IT methodology is to allow you to do design late and to reduce the cost of change should it become necessary.

If we look back to the slow paced iterative world, where developments happen in years, monolithic iterative IT projects often existed as the only game in town, disconnected, serving to replace existing physical process with identical digital solutions procured by managers only able to procure a solution they can perceive.

They designed early, created long backlogs of work, increased complexity, and made change nearly impossible.

So it’s easy to see how this world could miss the massive cultural impact of the cloud, mobile, single identity SoMe, big data, and deep learning in driving the possibilities of IT and human behaviour in creating solutions for them.

This is all mind numbingly obvious, and to a degree passé. Most corporate customers understand and consult experts to develop and design their IT products, and have experts run the agile process, with good stories being fed into tight sprints, overseen by experts managing the portfolio (and any debt).

But I where I see process debt being produced in spades is in corporate. We have pretty much all complained about the amoebic speed of corporate.

Part of the problem is that whilst IT has a reputation for being disruptive and fast paced, most corporates still believe that their specific monolithic processes of the past are the way of their future.

They believe that their business (and boy do they love talking about understanding their business) is today what it was yesterday. It isn’t:

The business of communication is silicon valley.

The business of transportation is silicon valley.

The business of entertainment is Silicon Valley.

The business of diagnostics is silicon valley.

The business of shopping is silicon valley.

The business of procurement is silicon valley.

The business of time is silicon valley.

The business of education is silicon valley.

Hell, the business of business is silicon valley.

Whilst not all companies executing in the industries above may be silicon valley startups, in order to succeed they will have had to learn to directly compete with, execute as well as, as fast as and with as clear an understanding of the future as silicon valley does in order to survive let alone differentiate or thrive.

Recent history teaches us that companies who want to execute in their traditional business have to learn to execute both in the technology of their products and in the agility of their corporate culture and processes.

This is more than merely having a mobile and pinging emails around. This is about culturally understanding in the broadest sense how SoMe, big data, deep learning, and automation can destroy their very raison d’être and that their main competitor is no longer the rest of their industry. It’s silicon valley.

Internal processes (by which I mean leadership, planning, operational management, execution, problem identification and solving) must start paying attention to the shifts in technology and embrace agile structures, creating stories, designing late, and reducing the cost of change.

It’s not about having a flat management structure with an expert somewhere in there who can manage IT products they groupthink. It’s about getting the culture right up the chain so the narrative of a company’s perceived future, and therefor the technical debt it accumulates, affords it a viable future.

The refusal to accept that simple, cloud driven, mobile, connected, automated and learning processes can apply to corporate is allowing corporates to first build and rely on, and then  propogate the creation of slow, complex, dependent, and debt ridden processes that will expose them to massive risk.

Corporate processes need to be redesigned, and in corporate structure as in agile dev ops, the purpose of design is to allow you to plan then execute quicker and later with the primary goal of reducing the cost of change.

Ignore the cost of change at your peril.