This article is based on an online round table "Beyond Agile' organised by Pointury on February 3, 2022, where 20 digital leaders met with F5, CGI and Pointury.
On Thursday the third of February 2022 twenty digital leaders met with Ruben Smolders during an online event organised by Pointury and sponsored by F5 (experts in multi-cloud, cybersecurity and agile developments) and CGI (consultants with expertise in amongst others business agility).
Ruben Smolders, currently Platform & Integration Tribe Lead at SD Worx (a division of around 150 software development employees) explained us the Balanced Management Model, which he implemented in the two largest software development tribes (both around 200 employees) at SD Worx. The model was developed to solve a number of pitfalls in the "Spotify” model. The “Spotify” model is a model implemented in 2012 by the Swedish music streaming company Spotify and which was adopted by several other companies in the services industry. SD Worx itself also implemented Spotify in 2018. After the pitfalls were solved through the Balanced model, the tribes of Ruben reached a higher effectiveness, increased efficiency, better predictability, and an increased engagement of all stakeholders.
Setting the scene
While most participants had experience with agile, they were looking for best practices to speed up development, to be even more product oriented and to involve the entire organisation. They also looked forward to compare their way of working with what other companies are doing and get inspired by the expertise of Ruben and other CIO’s. Some are facing the challenge that while IT has adopted an agile way of working in the last 2 years, business is still used to a waterfall approach. It was clear that adopting the agile approach in the entire organisation and better integrating business and IT is still in progress in a lot of companies
What is the biggest pitfall in an agile transformation?
The round table kicked off with an on-line questionnaire of the biggest pitfalls of an agile transformation according to the 20 digital leaders in the meeting.
It was striking to see that these pitfalls, submitted by the participants to the round table, were very similar to the pitfalls which SD Worx had encountered. Especially the one on “losing the big picture”, offered a seamless transition to the first pitfall of the Balanced Model
Commitments on a longer term in agile
While pure agile prescribes commitment of two weeks, nearly all of us felt that commitments should be for a longer period than that. Let’s not forget that internal or external customers sponsoring the developments (Sales, Finance) need to know on a longer term than two weeks what they will get from IT. Finance most often has a yearly budget cycle and only very rarely Sales can limit itself to only selling what is already existing. Sales needs a roadmap of what will be coming. A purely bi-weekly approach (as prescribed in Scrum) is not sufficient here.
Experience with Agile at SD Worx
The Balanced Management Model
To get to Balanced commitment SD Worx introduced OKRIS: Objectives, Key Results, Initiatives and Sprints. The key is not to commit on a delivery of specific output of feature, but on a business outcome and to keep quarterly agility in outputs/features. Balanced uses a four-layered approach
- Objectives : Define long term (5 to 10 years) North Star objectives
- Key Results : Look for a clear simple key metric that measures the result. Describe the expected result as an outcome, that needs to be achieved on 1 year
- Initiatives : Are defined and committed by the teams themselves on a quarterly basis on how to achieve the outcomes. The upper right-corner (build a tunnel instead of a bridge) depicts the relation between Key Results and Initiatives in a visual manner.
- Sprints : are short-cycle follow-ups of the quarterly deliveries. It may not be the best way of working for all teams. They are therefore free to choose the method (Waterfall, Kanban, Scrum, Scrumban,…) which is best for them to achieve their committed quarterly initiatives. Because scrum does not work for every type of team in a product development organization.
Organizational charts
On the question whether agile made roles & responsibilities more unclear than before, more than 75% answered “yes”. SD Worx had the same problem and that’s why they made a new org chart instead of just putting the new agile roles on top of it.
Existing scaled agile models did not help here: either they describe roles, but not org charts (like SAFe), either they result in complex matrices with a lot of indirect feedback between individuals (Spotify). That’s whySD Worx implemented a “Balanced” org chart.
In the Balanced Model the product manager, who focusses on doing the right things, is tight to the hip with a balanced leader, who focusses on doing things right. Together they report to the product tribe leader. Product owners work very closely together with the IT teams (scrum master, solution architect, analyst, developers and testers), resulting in better understandings (and more effective products) of the world of the customer and the world of budgeted
Budgets are made on a tribe level with focus on outcomes. Outputs are not budgeted. They are only a means to achieve an outcome.
For bigger tribes a domain architect has been added, who defines e.g. integration or solution strategies between the teams.
At a higher level in the organisation there is (rather small) enterprise architecture team which oversees enterprise architecture and enterprise tools and technologies.
Managed innovation
In extreme agile implementations, the software teams have autonomy over the tools and technologies they are using. That leads to several problems
The balanced model foresees a lightweight structure to overcome thisdifferent boards: a tribe has an architectural governance board, a balanced leader community, a scrum master community, a product owner community and guilds. In boards, guardrails are being set and tribe management is involved (eg. we are using .NET and not Java or we standardize on 1 service bus technology, etc.). Communities are exchanges of best practices between peers. The content is not managed at tribe level, the only thing which is managed that this peer sharing actually finds place. Coming together in communities is an important part of learning in agile. In communities people come together as peers, on purpose without a hierarchical structure Guilds are spontaneous, unmanaged, gatherings from enthusiasts around a certain topic and often the labs for innovation topics which afterwards end up in a presentation on one of the boards. All the three layers are needed to come to balanced & managed innovations in a safe manner.
In order to make the team more robust and less dependent on absentees, employees need to develop adjacent skills, in other words: become T-shaped profiles (the vertical axis meaning a specialization, the horizontal the development of adjacent skills) In soccer this would mean that an offerer might have to act as a defender when needed.
The model is still evolving as there is continuous learning.
Training on the full model (including the levers about T-shaping and neuroleadership in Teams), is possible at NCOI in April.
A pdf of the full model can be downloaded at www.managementbalanced.com
A one-pager of the model is available via www.managementbalanced.com/
The TED talk of John Doerr is available on YouTube.
