“Our customers are leaving for competitor X. We starting to think it’s because their apps are better” says the CEO to the CTO, “Why is it ours have such low usage figures?”

“We develop new features but it often turns out they were the wrong idea in the first place, or by the time they’re live our competitors already have better versions than ours” replies the CTO.

“Find out how to be more Agile” the order translates to as it hits Technology. A consultancy is hired to tell most of the tech folks at the Enterprise what they already know: the time it takes for an idea to make it into production (aka ‘cycle time’) is too long. Apparently quarterly concurrent releases across 30 apps, of which just a few are customer-facing, managed by 100 IT ops folks aren’t conducive to high velocity IT change. So how to change?

Well its good news and bad.

The good news: despite what most software vendors would have you think, the majority of the change is organisational. Buying a PaaS isn’t a necessity, although it may help. This change hasn’t got to cost a lot in software license terms.

The bad news: organisational change is hard.

TL;DR

It turns out the major changes can be summed up into two changes:

• Switch to smaller teams & decouple them in every way. Deliverables are ‘microservices’
• Switch from the project to product model
• Treat each product like a Lean Startup
• Decouple environment dependencies

Microservices & Conways Law

The fastest way to deliver software is to put your most suitable developers into one team, allow them to use the most suitable tools to get the job done, and leave them to it until their complete.

Of course Enterprises have structure and standards that have some overall benefit in operating at such large scale, however these are going to get in the way of quick delivery. CTOs can either accept these as parameters, in which case delivery speed won’t change, or start decentralizing these rules and putting the responsibility on each team to meet the standards their own way.

Mel Conway wrote back in the 60s that the structure of the deliverable will represent the structure of the organisation that built it. Putting your resources into one team, working on one deliverable, will produce one ‘product’. The term ‘two pizza’ teams has sprung up to define a max team size: if it can’t be fed on two pizzas, the team is too big.

The most decoupled architecture is to depend on other services at runtime, so that they can be modified / switched out / upgraded without affecting anyone else’s source code. Put this into practice and single teams are going to start producing ‘microservices’, a term which really means an encapsulated app for providing a single service. They’re the opposite of monolith apps.

By keeping backwards-compatibility as a standard, the release of these independent services can be done in isolation, avoiding the nasty multi-app release weekends those in Ops have come to know and hate.

If you want to drill down into this, the absolute best explanation I’ve seen over why Conway’s law should be used to dictate organisational change is by Mike Amundsen.

Products not projects

The project process wastes a lot of time: all the analysis, planning, estimating, fund allocation against estimation, resource allocation, etc. all take up elapsed time and can take developer time away from actually apps. Plus the dispersal of the project team after completion can leave the app languishing without proper dev support after go-live.

Most Enterprises are discovering that the project model no longer fits for in-house developed apps, particularly those important ones that are always changing, and it’s best to keep developers assigned to an app & churning out features. Of course this is a tricky change of mind set for those who pay for the software, from a fixed price for a a project delivering a fixed set of features, to a fixed price for a team of devs for the year with no guarantees of any one feature delivered. However seeing past this transition can really pay off because the product process, having no unnecessary ‘stages’, gets software delivered significantly faster than projects.

Lean Startups

Eric Ries’ book ‘The Lean Startup: How Constant Innovation Creates Radically Successful Businesses’ is an amazing read. He loosely classifies a startup as any new team anywhere trying to do something new. The first step requires us to admit that nobody really knows what the customer wants except themselves, so the constant and only goal for the startup is to attain that knowledge.

At Enterprises the requirements usually come from ‘The Business’, someone with business domain knowledge working with a BA to define what they think the customer wants. Applying The Lean Startup to Enterprises would result in product teams iteratively developing new features, exposing them to specific customer sets after each iteration, observing usage patterns (no focus groups!), and assessing success. Then deciding to keep the feature and develop it further, or delete it and develop some other feature based on the usage results. This continual process of assessing end user benefit & removing anything that does not directly provide it, is how successful apps are managed, and kept free from the kind of code bloat that can poison long-lived apps.

Direct Environment Dependencies are evil

Apps are generally going to depend on other ‘services’, particularly at Enterprises. Whatever form these service dependencies take, even with loose coupling the temptation will still be to have your app’s DEV, TST, UAT, PERF & STAGING environments all connected to the equivalent environments of their dependant services. It’s at this point the hard-wiring causes delays in delivery, losing days of testing time when:

• Environments are temporarily unavailable
• Environment refreshes cause data to be out-of-sync
• Data state changes dynamically and not all linked environments receive the update

For me this specific area seems like the most under-addressed area of technology right now. I’ve seen organizations use Service Virtualization tools for providing virtual copies of services, databases, messaging infrastructure and the like. Some organisations like HomeDepot are putting tools like CA LISA at the centre of their Agile Transformation, which I’m certain will not be an inexpensive decision & shows they’re sure decoupling of environments is key to success.

Last time I checked Gartner there were only 4 main vendors: CA, IBM, HP and Parasoft. However what the 4 solutions on the market right now have in common is that they are much too centralized: you can produce many copies of your main central database, however it is provided via a centralized SV infrastructure. And the cost of entry is way too high.

For now, manually-developed stub services are still the most flexible way to decouple your environments. Eventual close coupling, say of Staging environments, is inevitable, however it shouldn’t be necessary right the way up to production.

Don’t get fixated on tools and software

As I’ve tried to show above: Agile Transformation is mainly about organisational change, not buying infrastructure.

In comparative size, if organisational change were as big as a dog, the relative amount toolset change would only be as big as the tail of the dog. And using that analogy further it should be the larger organisational change that drives the tool change, after all it is the dog that wags the tail, not the other way around.