My notes from Platform Thinking by Evan Bottcher

As the title suggested this is my notes from the Platform thinking meetup. As usual, I did a little googling to get a sense of the speaker

Among other things, he also contributes to Thoughtworks technology radar which is super cool.

The event detail can be found here.

Writer’s Note: Please be advice that is my best attempt to captures and make sense of the talk that Evan gave. While I tried my best, it might not be accurate or just plain wrong. Keep please that in mind while you are reading through this :)

Its impacts are somewhat limited mainly because the projects are still being treated like “skungworks”

He compares it to Conway’s Game of Life where small sparks happens within the organizations and before it could spread. The projects were delivered and teams disbanded. And things were reset.

The question then becomes

How to create everlasting change?

An example he gave was that it is easy and fast to be “Agile” on the front-end projects but it becomes a real challenge when the project touches on backend systems. He mentioned working for a Telco company in Australia where he met similar challenge.

We all know the ideal Agile team size is 7 +/- 2 which is known as 2 pizzas team. Where the whole team can be fed with 2 pizzas.

On a larger and more complex system, Evan suggested that this might not work.

Writer’s Note: How to effectively scale Agile has been a subject of recent debates and explorations. We won’t be touching on those here.

Evan mentioned 2 things

  1. Digital delivery to business
  2. Shared capabilities becomes internal platforms

The goal is to create a completing product to the user. Even if the product is meant for internal use. Why would other teams or services use your product/service as oppose to others?

One good practice that he recommends is to build your product into cereal box. One example of how to play this game can be found here.

Evan went on to share “The playbook” on how Agile can be scale successfully.

  1. Depreciate ”Project” as vehicle of delivery. This is because Project team got disband after the project is delivered. Instead, it is better to keep the same team and have them delivers on “initiatives”
  2. Each team own a full slice from customer layer to business domain all the way down to infrastructure ( See image below for illustration )

3. Put projects in to stable teams that are empowered with a high degree of autonomy. They will become domain experts and also create a sense of ownership.

Writer’s Note: Please note that this is a little more to this. This is what is known as Spotify’s team structure. A good place to start reading more on this can be found here

When the organization is adopting Agile on a large scale. Evan observes 5 things that happens.

  1. Architecture: Technical design responsibilities are delegated to teams. There is be no more “Architecture forum”. Although, the architectures are still very relevant in helping setting up guidelines and assist team. More on this Evolutionary Architecture and Podcast episode released on 11/3/2016.
  2. Program management: No more PMO, smaller size initiatives and outcome focused AKA Lean. One example Evan gave is an Australian company where they will release small funds to initiatives. This is known as “Lean Governance” where the executives do a “Wall Walk” twice a week to get updates on the currently active initiatives.
  3. Integration and Data: Accessible and robust. No “API” team. With high quality data steam.
  4. Infra & Ops: No more tickets. Self service API, Team provision, Team configured. The Goal is Infrastructure as code. Large enterprise might have rules and regulations against cloud services. Evan’s Advice is that you just need to start small and slowly bring it to the “tipping point” within the organisation.
  5. Continuous Delivery: Confidently ship to production without breaking things. No more “weekend of pain”. The recommendation is to start with one service with the highest demand. The key is team must own their own pipeline to production.

There is a balance to be consider with platform and team autonomy. If the platform is too centralized then the platform will be too rigid but if the autonomy is too high, there might be a lot of replication.

How might we know if we are moving to the right direction?

  1. Start with measuring time to market
  2. Look at operating cost

Sadly I sat too far at the back to hear the questions properly during the Q&A section. So I will try not to take future risk to transcribed my notes here. Except my own question below :)

Tech team and business celebrate together on business impact achievement

I found the event to be a great and insightful evening. So my thanks to the thoughtworks team for hosting this event.

— Pondd —