Resolving impediments to flow and removing unnecessary sources of cognitive load can make culture issues disappear in organisations, Nigel Kersten argued. Start with a clear strategy that is easy to communicate, then follow the path to creating stream-aligned teams and platform teams, he suggested.
Nigel Kersten spoke about enabling fast flow in software organizations at FlowCon France 2024.
For a long time, DevOps was useful just to make it clear that you wanted to change the traditional relationship between the teams that built software, and the teams that were responsible for maintaining and running that software, and that you wanted to implement more sophisticated automation, however Kersten says he doesn’t believe that’s the case anymore.
He advised not to focus on "fostering culture" or "fostering DevOps" as a primary goal. Instead, focus on improving fast flow and low cognitive load for your teams involved in software delivery. As you resolve impediments to flow and unnecessary sources of cognitive load, then the "cultural" issues will start to disappear, he argued:
Delivery will become increasingly more predictable, friction between teams will be reduced, and teams will have more time to invest in new skills, automating processes, and implementing self-service interfaces, all of which will continue to free up more time to create an environment of continuous improvement.
Technological improvements like containers, VMs, infrastructure-as-code, software-defined-networking, collaborative version control, and CI/CD can make it possible to fix cultural issues around organisational dynamics and bad product delivery, as Kersten explained in how technology can drive culture change in software organisations.
One of the primary drivers of the early DevOps movement was a complete lack of alignment between the people who built software, and the people who were responsible for running it in production, so we all spent a lot of time focusing on ways to increase collaboration in order to improve software delivery, Kersten said. This was great, but over time collaboration itself started to become the goal, and that’s just not a productive way to run a software organisation, he added.
Kersten referred to Team Topologies and the increased emphasis on platform engineering that we’ve seen emerge over the last few years, which both recognise that collaborative interactions are not universally appropriate:
Collaboration between functions like development and security is great at the design phase for a new product, but the goal should be to move towards X-as-a-service interactions and minimise collaboration over time.
Before you start hunting around for an internal developer platform solution, or reorganising people into stream-aligned teams, make sure that you have a clearly defined strategy that is easy to communicate, Kersten explained:
First, this is more important to get right than your organisation structure and platform team adoption, and secondly, it’s necessary in order to define the right value streams, decide whether you should have a platform team, and define the high-level goals for success.
Kersten referred to the book Good Strategy, Bad Strategy and the model used to define a strategy: a diagnosis of the situation, some guiding principles for addressing the situation, and a set of concrete actions. Strategy without an action plan is just a vision statement, he said.
If you’ve got your strategy and actions in place, then the path to creating stream-aligned teams and platform teams will be reasonably obvious, Kersten concluded. He suggested focusing on creating and amplifying feedback loops, both internal, and external:
Ask yourself: are your developers able to experiment quickly, and share those experiments easily with colleagues and stakeholders? Are your stream-aligned teams aware of upcoming changes to the platform itself? Does your platform team treat their stream-aligned teams as customers? Do they do product discovery and user research to guide their roadmap?
If the answer to these questions is no, then focus on removing whatever barriers are in the way of a fast feedback loop and user outcome-driven culture, Kersten concluded.