In the world of agile; Trust is good, control is better

What this truly means for your organization is up to each of us to interpret but one thing is for sure, people can get very philosophical when talking about agile.

One of the more tangible concepts in agile is the notion of “you build it, you run it…”. The idea that autonomous teams owns and manages everything from requirements to operations is a very powerful concept and if implemented correctly can provide huge benefits when it comes to speed and agility of a product or service. Having seen this power in action myself, I am a firm believer of the agile enterprise. With that said I also recognize that there are several challenges and risks involved when moving down the agile road. Things like top management support and culture fit all have an important part to play. Another area or risk that I personally have seen and experienced is technology sprawl.

Kids in a candy store

Imagine you hand over the keys to a large car dealership with a huge variety of cars to a bunch of “car techies”. Although the Sportscars, SUV’s and Station wagons all was made with a specific purpose in mind, to the techies they are just toys that just must be tested and taken for a spin. Much like kids in a candy store – they simply want to try it all. The same scenario you could apply to Cloud Engineers part of a self-governing agile team. Give them the freedom to use whatever tools or platforms they want and you can be sure of that they will grab any chance they get to try a new technology, a different CI/CD engine or a new cool database for a “spin”.
Overall this isn’t necessarily a bad thing, since exploring new technologies and over time challenge your technology choices should be part of how all organizations operate. But it can become an issue when the technology sprawl becomes the “new normal” and basically is left to its own destiny.

I have worked within organizations that purely based on their strong philosophical belief in the Agile way of doing things and an over exaggerated conviction in self-organizing teams simply have let go of all type of technical control and/or governance. Not surprisingly the end result in organizations with a large number of product/agile teams is that they end up with just as many programming languages, databases and CI/CD tools. Another effect I have seen is the good old “Analysis Paralysis” syndrome. Individual teams sometime tend to over-spend time on so called “evaluation” of various technology options. It’s simply way too much fun taking all this cool new technology out for a spin so instead of moving forward and start to deliver value, they are stuck in “evaluation mode” way too long.

Once again, I am not pushing for the notion that exploring and evaluating new technologies is all bad; it’s great. But what I do push for is that it needs to be done with a sound “cost/benefit” equation in mind. Is there truly value in testing yet another CI/CD platform or should we just use what everyone else in the organization is using?

Tech Radar to the rescue

There are of course many ways to provide technology guidance and governance. Some companies might have some type of Enterprise Architect group that provides this function or they have rigorous design review board meetings and processes. Lately a new concept based on the Thoughtworks technology radar have become popular.
Basically, this is a very intuitive “maturity like” model that can be used to communicate the technology strategy and guidelines for an organization. The model is not by design prescriptive. Instead it provides high level guidance and principles to use when making design decisions – i.e. a common point of view to lean on.

The model is divided into four main quadrants; Techniques, Platforms, Tools and Languages-And Frameworks. Inside each quadrant are several so-called rings named; Adopt, Trial, Assess and Hold. Inside each ring there are a number of ‘blips’ (just like on a radar screen).

A blip in this context is a technology or technique. As an example, inside the quadrant ‘Languages-And Frameworks’ there could be a C# blip, a Node.js blip and a VB6 blip. Each blip is part of one of four rings,

• The Adopt  ring represents ‘blips’ that an organization wants their product teams to seriously consider using. The basic idea is that you don’t have to use it, but the blip has been evaluated as something where there’s no doubt that it’s proven and mature for use.
• The Trial  ring represents ‘blips’ that an organization think is ready for use, but not completely proven as those in the Adopt ring. For most organizations this means that new products and/or PoC’s can be done using these.
• The Assess  ring are things to look at closely, but not necessarily trial yet. Typically, blips in the Assess ring are things that an organization think are interesting and worth keeping an eye on.
• Finally, the Hold  ring is for things that an organization wants their product teams to avoid or stop using. The reason can be that the ‘blip’ is not considered to be mature enough yet or it could mean that the blip is “end-of-life”.

So, to summarize, organizations could use this model to create their own radar to communicate their view and high-level guidance on the technologies or techniques part of their own strategy.
Self-organizing teams with a large degree of technology freedom are great but I am a firm believer that a little bit of guidance in the form of a company tech radar will in the long run provide huge benefits. The cool thing is that this model and concept is all “open source”. If you want to check it out and start creating you own Radar just go to https://github.com/thoughtworks/build-your-own-radar clone the repo and off you go.

See ya in the cloud,

Carl-Johan Tiréus

CJ has a broad experience in all aspects of IT/IS-architecture and software development and has worked on a variety of architect and technical projects delivering solutions for fortune 500 clients. He has technical expertise on the Microsoft platform in general with Azure/Office365 cloud solutions as key focus. CJ is AWS & GCP solution architect certified and well versed in all major platforms.
Specialties: Azure, Google Cloud Platform, AWS, Office365, SharePoint, Enterprise Search, .NET Architecture, ITIL/Service Management, Consulting and Business development.

The opinions in the blog are the author’s personal views and not that of Capgemini.