I often find myself in discussions about the desirability of a frequent software delivery to clients and businesses. The most common argument against frequent delivery is that software delivery is perceived as interruptions of daily business, and represents a risk to the business at hand. Not seldom, processes for managing change are designed to slow down change rate; driving the "transaction cost" related to deploying software.

I believe that the fundamental issue at play here is a lack of trust throughout the business value chain. In plain English; IT (or a software vendor for that matter) is still deemed a support function; not an integral part of business value creation. Moreover, I predict that companies that continue along this line of reasoning will lose their competitive edge and be replaced by competitors that are able to integrate the operational value chain all the way from IT development and delivery to business performance. This is particularly true for businesses that are subject to the ever increasing rate of digitalization that is going on….and the number of industries that stand on the outside of digitalization seems to be dropping rapidly.

Research in the field of DevOps offer support in favor of frequent delivery of software. The perhaps most prominent research in the field is presented in the State of DevOps report. In the 2018 edition of the report, the authors state that "a common industry practice, especially in government or highly regulated fields, is to approach throughput and stability as a trade-off. But our research consistently finds that the highest performers are achieving excellence in both throughput and stability without making tradeoffs." The report presents compelling evidence for the relation between software development and operation practices and business performance.

This is consistent with my experience from leading software development organizations over the past decade and half.

Moreover, the frequent delivery of software is really just an extension of what I find to be sound principles of strategy execution. As described in "The 4 disciplines of execution" (book by Chris McChesney, Jim Huling, and Sean Covey); an crucial element in achieving important goals is to have what they call a "Cadence of accountability". The point of a accountability is to be able to "highlight successes, analyze failures, and course-correct as necessary". Also, the deployment of frequent accountability allows you to focus on lead measures; essential predictors of business success available early and frequently. They offer this as a complement to lag measures, which measure business outcomes but are often available too late to found basis for analysis and decision making along the way.

Working with software development and delivery, it is often necessary to deploy software so that it sits in the hands of users in order to enable analysis and decision making based on reliable facts. Thus, I conclude that the frequent delivery of software is an enabler for business execution - not a risk to it.

Den operationella värdeströmmen inom ett bolag är ett sätt att beskriva hur information förädlas inom bolaget för att sedan nå en kund eller användare i form av en ny eller förbättrad tjänst eller produkt.
Men hur gör man på bästa sätt för att för att skapa värde? Någon måste ha gjort det förut som vi kan kopiera? Eller finns det möjligen ett ramverk man kan implementera för att med hjälp av best practice bli ett bättre företag?

Björn Persson och jag utforskar denna och några andra frågor i detta fjärde avsnittet av Agilt & Företaget, och landar i att det finns en förmåga som många företag behöver ha i dag - den att ständigt utvecklas för att optimera sitt värdeskapande. Frågan är om best practice håller måttet i en konkurrensutsatt och snabbt rörlig verklighet?

Kunderna då?
Men kunderna då - accepterar de verkligen snabba leveranser och ständiga uppdateringar? Titta och lyssna, så delar vi med oss av några exempel på vilka reaktioner vi fick på Volvo Car Retail Solutions.

Att bli mer agil är sällan ett eget ändamål. Organisationer som kallar sig agila gör det av en anledning - de linjerar sina förändringsinitiativ med företagets långsiktiga mål och existensberättigande. Det kan handla om att göra en förändring för att säkra överlevnaden eller att starta en (ny del av en) verksamhet där osäkerhetsfaktorerna är betydande. Poängen är att "agilt" som begrepp tonas ned och företagets mål står i centrum.

I detta avsnittet av Agilt och Företaget pratar Björn Persson och jag om ett case vi båda har varit involverade i - en agilresa på Volvo Car Retail Solutions (VCRS). Samtalet kretsar kring den inledande fasen i förändringsledning - där frågan om varför en förändring behövs är central. I denna delen av resan är agilt som begrepp inte av någon större betydelse, utan det handlar om att skapa förståelse för att en förändring behövs och landa känsla och förståelse för detta i organisationen. 
​
Det finns olika sätt att ta sig an frågan om varför. I vårt samtal berör vi det som John P. Kotter kallar för ett "sense of urgency" med referens till boken och konceptet "8 steps to change". En teknik som vi har använt och refererar till kallas "Pre Mortem" och introducerades 1998 av psykologi-forskaren Gary Klein. Det är en teknik för att minimera partiskhet/snedvridning vid beslutsfattande (engelska: De-biasing technique), och kan användas i detta sammanhang för att skapa just ett "sense of urgency". Om du är intresserad av lite mer information om tekniken kan du kolla nedan videos på ämnet:

• Kort beskrivning av Pre Mortem av Guy Kawasaki: https://www.youtube.com/watch?v=zN-PT8PYjTo
• Kort beskrivning av Pre Mortem samt diskussion kring tekniken av Daniel Kahneman: https://www.youtube.com/watch?v=MzTNMalfyhM

Detta är det första av flera avsnitt där vi delar med oss av resan på VCRS. Håll utkik efter fler avsnitt under veckorna framåt.
​ 

Jag är mycket stolt över att kunna introducera programserien "Agilt och Företaget" som görs som ett samarbete mellan ProAgile och Kinactic.
​
Tanken med serien är att koppla samman agila arbetssätt, koncept och mindset med företagsstrategi och under kommande program belysa olika ämnen på detta temat.

Programmen leds av Björn Persson som är agilcoach på ProAgile och Thom Birkeland som är CTO på Kinactic. Båda har under flertalet år jobbat med mjukvaruintensiva bolag och där på olika sätt fokuserat på organisationsutveckling genom såkallade "Agila resor". En av lärdommarna är att agilt inte enkom är en angelägenhet för utvecklingsteam eller -avdelningar, utan snarare direkt berör bolagens strategi och väg till framgång.

I dagens avsnitt berör vi vilka externa drivkrafter i marknaden som motiverar att agila arbetssätt bör vara en del av ett företags sätt att bedriva sin verksamhet.

Ever been involved in a software system that has gotten hard to maintain and develop over time? No sh*** Sherlock, you might say, who hasn’t? I believe most developers have experienced this, and that the issue is somewhat inherent in working the life cycle of a software system which spans a longer period of time, and employs a certain number of people. OK, that isn’t very tangible - I know - and I don’t have any scientific data to back it up, except for heuristics derived from personal experience and other narratives.

Size matters
I stumbled upon this article by Michael Feathers, that seems to point in the same general direction. I think it is safe to say that complexity is bound to increase with the size of the system. As you introduce more functionality into a software system, which for example is built around a monolithic architecture, you will eventually find yourself in a state where changes to one part of the system might affect another part of the system, even when it “should not”. This impairs developer productivity. Many narratives also speak to the fact that when introducing new team members it takes increasingly long time before they are productive.

Microservice architectures
While not a new concept at the core, Microservices is a development of the idea of component based software system that has a very promising outlook to address just these (and some other) issues. The exact definition of a Microservice architecture is not carved in stone (it may be a little early for that still), but there are a few resources out there trying to describe what it is, for example this article on the Martin Fowler blog, which states:

"In short, the microservice architectural style[1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API"

As explained in this Computer Weekly article, the developments we have seen over the past few years where HTTP and XML/JSON have become de-facto standards for interprocess communication across platforms - architectures that are components in both source code and runtime are much more accessible in reality now than when the industry was struggling with compatibility issues inherent in protocols such as RMI, IIOB and RPC.

Architecture requirements need to be broken down
Back in the days when I was a consultant, a requirement specification from a client sometimes would contain a variety of the somewhat naïve statement that “It should be easy to add functionality to the system over time”. The scope would typically be a custom built software system. As a consultant, how do you deal with a statement like that? It is hard to test, and when the time comes to actually add features to the system, you are probably gone. Working for a product company, however, the requirements on the architecture becomes extremely important because (soon enough) the choice of architecture will govern (as in restrict or enable) everyday work for pretty much everyone in the company from developers, through sales reps to senior executives. In what follows, I will try to break down what the simplistic statement would (should?) entail in many cases. Chances are, if your ambition contains elements listed below, a Microservice architecture is for you.

To the point, 4 main drivers for a microservice architecture
So, how do you end up choosing a Microservice architecture for your product? There are a number of articles out there focusing on the technical benefits to a Microservice architecture. I intend to talk about some aspects related to business risk, scale and team composition that in my experience will drive your decision from a business point of view. It is indeed my opinion that the choice of architecture eventually defines your company’s ability to operate and innovate consistently over time.

In my experience the following key requirements will eventually lead to the choice of a Microservice architecture, and it will secure the future of your organization.

The ability to operate under risk and uncertainty
If you’re in it for the long run and don’t have all requirements when you start your venture, you need to be flexible and agile (for lack of a less used term). Starting a new software product, be it a vital part of a product company or a support system for a certain business unit, has a risk and uncertainty component to it. As someone who is tasked with building the software, you are likely not to be equipped with a full and flawless understanding of the needs of your customer. You might be nodding in agreement, thinking that is where agile and lean comes in to play? You’re right of course! I do, however, want to add to the mix that in order to be agile for real, you need an architecture that supports being agile. If you do, you can accommodate risk mitigation more easily than if you’re struggling with a growing monolithic software system. The risk will probably take on different shapes as times passes (in the beginning, you might want to know that you’re in the right area at all, later you might “just” be adding features to a thriving product).

By modularizing your architecture, you can counter play risk scenarios more efficiently, deploy new or updated features faster, and even remove features without the need for surgical precision operations to carve out code from your project.

The ability to scale
Scale is a multi-faceted term in this context. I don’t think I will upset anyone by claiming that most companies would be thrilled to run a business that is successful enough to require more servers to accommodate customer demand. If the system is monolithic, we are used to horizontal scale strategies; you add more servers as needed. When considering scale at a broader range, you may want to include other dimensions such as

• Functionality - how do you add more functionality to the system while guarding the parts of the system that are already in place?
• People - as complexity increases in your system, how can you add or replace people in your team in a timely fashion?
• Geography - how can you cater for a situation where certain parts of your application has different requirements in different parts of the world?
• Asymmetric resource requirements - certain parts of your application may require more computing resources per time than others, and it is nice if you can scale these parts independently from other parts.

Again, a Microservice architecture allows you to scale along all these dimensions quite easily.

Cater for innovation
You want to test new things, add and remove functionality in a relatively easy manner, and thus keep up an innovation speed that beats competition. To do this in a manner that does not intrude on current customer base, and that allows you to test on a selected few is far easier if you embrace a Microservice architecture than if your are confined to a monolithic system.

Team organization
The impact of your organization on your success as a software development team has been discussed at length by others; not least in Conways’ law. If you are familiar with Fred Brooks’ The mythical Man-month, you may subscribe to the idea that adding more people to a team will cause overhead that costs more than what you win. At the same time, you want to add more features to your product to satisfy customer needs in a manner that keeps you ahead of competition. So, if you can create an architecture that allows you to keep teams small and (as much as possible) independent of each other, you’re on to something. At Amazon they coined the term Two-pizza teams, to define a full team as per the amount of pizza needed to feed the team members: When you need more than two pizzas to feed the team, add another team - and at the same time - add another (set of) services the new team can work on independently from existing teams.

Should you start off with a Microservice architecture?
I suppose you can argue both ways here. On one hand the Microservice architecture will give you many advantages. On the other it will also make your initial development effort somewhat more advanced; i.e. it will take longer for your team to deliver initial business value. There is a certain overhead involved in getting up and running, both in development, but also in operations - Microservice is not a free lunch, as Benjamin Wotton states in his article (don’t forget to read the comments, too!). Some people even think that you shouldstart out with a monolithic architecture and refactor later to a Microservice architecture. If I were to break it down to a simple model for decision making, I would say

• If you are an early stage startup with an unvalidated business idea -> build something that works and will validate your idea first, then decide upon architecture
• If you have a validated business idea and have started to gain some traction with it, make your long(er) term technology strategy (and consider a Microservice architecture in that process)

How do you make it work?
So, you have made a choice to go with a Microservice architecture, how do you go about making it work in real life? That is the topic of a later post.

Comments?
​Yes please!If you have experience with Microservice architectures, or just a general interest, I would love to take part of your comments in the comments section. Do you think that other values should be taken into account than those included above when choosing a Microservice architecture? What are the drawbacks?