You CAN change your Culture if you want to Maximize value
Apply Time Value of Money Principle to Software Development and Delivery
In my previous post, I said:
DevOps is fundamentally a software development practice.
To adopt this software development practice, we have to change the software development culture. A mindset shift is needed:
“We are a software company with wings” — CIO of an Airline company
Any organization can adopt this mindset and create a modern software development culture if you want to maximize value. The way to maximize value is by reducing cycle time.
“Speed wins in the marketplace” — Adrian Cockcroft, Netflix, Battery Ventures
Make speed your friend. Every organization can deliver at speed and scale without sacrificing quality.
In order to deliver software faster, the software must be built as independent services that can be stitched together via contracts (REST API’s) to form an Application or System. Monolithic systems have too many dependancies where things slow to a crawl.
Applying the Time Value of Money Principle to Software Delivery
Applying the time value of money principle is the key to unlock the value. So, why are the biggest enterprise not delivering software today or multiple times a day? It’s not that they don’t want to. It’s because after years of being in business, they have built up a lot of applications and systems. It’s not that easy to transform your software development organization much less the applications. Adapt they must though. However, the main issue is to recognize that if you want capture value fast, then the value needs to be delivered — ie. Running in Production. The more frequently you deliver that value, the better the return. It’s like compounding. If you deliver once a year or once every 18 months, it costs you the same total amout of development resources but you have delayed the capture of that value by a year or 18 months or more. Whereas, if you deliver value today or tomorrow, you can start capturing that value today or tomorrow.
Align your teams to business value.
Empower “2 pizza” teams
Aligning your teams to business value. How? By creating modern “2 pizza teams” that can build services independently.
Align teams to business value
Organize your teams using Conway’s law
There’s a way to retool your software development organization so that your teams that can deliver value faster by building services independently. Conway’s law, which basically states that organizations that design systems “are constrained to produce designs which are copies of the communication structures of these organizations.” The implications for software development are rather simple: the structure of our software is likely to reflect the structure of our software development organization.
If the organization has separate horizontal teams that each own different elements of a service, for example, one team owns the API layer, another one owns the business logic, and a third owns the data layer, then the virtual team that has to build a service that consists of all three have to constantly negotiate with the priorities of the horizontal teams. These siloed teams will have their own priority so if a team that is building “Service A” has to deliver a solution, they have to negotiate separately with each of these teams and this slows down the process. Creating virtual cross functional teams is simply papering over those communication boundaries. This is not going to achieve the speed, quality and risk profile that you need to deliver value faster.
This is a BAD idea
By creating vertical teams for each service where the team owns the API, business logic, and the data layers, the teams are no longer dependant on any other team. The key is the API layer. This is used to form contracts between different vertical teams so each team can move at their own pace and use the API to integrate or leverage other services from other teams.
Best Practice — Follow Conway’s Law
Best practice — Follow Conway’s law for teams that are building services that make up the system or application.
In order to deliver value fast, teams must be organized in a way that allows them to own it end to end. What Amazon calls — “you build it, you own it” through its entire lifecycle. But what is it that they will own and how many cooks do you need in the kitchen to own it?. That’s what we have today with Monoliths. Large teams of 100’s or 1000’s can’t possibly “own it”. The only way to have responsibility assigned in a way to measure accountability, is to empower “2 pizza teams” that own something end to end. This something is a service. A service does one thing and one thing well — single responsibility principle. Whether you call it a microservice or not, doesn’t really matter.