Upon going from an ART as an organizational structure to an ART as a means for execution, I found out first-hand how something as simple as a first draft can mess up the entire perception of an otherwise well-intentioned redesign.
1. INTRODUCTION
I have facilitated new team designs through self-organization several times before, offline as well as online, for hundreds of people. Of course, they have never been perfect, but I have learned from every single one of them.
Therefore, I did not think twice when I was asked to facilitate a similar session in my new ART. Yet, somehow, I failed miserably. Luckily, I survived to tell the story, such that you do not have to suffer the same fate.
2. Background
Before 2018, our company was mainly organized around projects. The average time-to-market was 18 months, which they realized would be way too slow if they wanted to succeed as a company in such a volatile and competitive environment as the energy industry with climate change lurking around the corner.
To reduce their time-to-market, and gain some transparency along the way, they looked to Scaled Agile Framework. The different roles and artefacts seemed easily applicable to their current organizational structure, so they implemented 8 ARTs within two years. The first of these is the topic of this story.
Three years went by and events such as PI Planning became routine – for better or worse, as there was no longer any focus on improving the ways of working. This resulted in nothing more than new, static processes and tools to comply with – and the ART was more an organizational structure than a unit delivering great products.
When I entered, in 2021, the ART was essentially organized in functions. Multiple teams were required to deliver their part to provide valuable features to the customers. Furthermore, every team consisted of specialized individuals within those functions.
This led to features being simply an aggregation of stories created by individuals, and epics an aggregation of features created by teams to maintain an overview of everything going on. This created an inside-out mentality with no focus on prioritization across and a lot of handovers resulting in low productivity and quality.
If you looked at our data at this point, our feature lead time was 3 months. This would seem great, down from our previous 18 months, but as these features were not potentially releasable increments, this data was untrustworthy.
Finally, we had a strategy of reducing our 80 interdependent applications to 15 with the use of microservices. But, as each Product Owner had customers with their respective requirements, no one was ever working on the long-term high-level strategy.
This is the story about how I tried to fully utilize the power of a team of teams.
3. The story
Upon redesigning our ART, we aimed to
- Optimize value delivery through better execution of our strategy and larger initiatives.
- Increase productivity and quality due to fewer handoffs.
- Establish a foundation for cross-functional teams consisting of T-shaped profiles.
- Reduce our actual time-to-market.
3.1 Before the ART redesign
No larger organizational change will succeed without some kind of communication.
One month before the redesign, we communicated the above background, benefit hypotheses, and that a change would take place. Our vision for the ART was A truly scaled agile delivery organization of flexible teams, applying best practices for built-in quality and pulling work from a shared ART feature backlog.
Two weeks before the reorganization, we communicated who would be impacted for now and how we would approach it. As we acknowledged a complete rehaul of the ART would create too much disruption when they still had 80 applications to maintain in production, we took an incremental approach which would also enable us to learn from our mistakes.
Some teams would stay as-is with their respective feature backlogs.
Three new teams (from now on referred to as green) would be established to support our strategy. This would be done by using a shared feature backlog.
Three other teams (from now on referred to as purple) would need to be redesigned as many people had gone to the new teams, and the reduced teams were no longer sustainable. These people were also highly involved in 24/7 support, which would need to be handled in a better way.
There was already at this moment a huge concern about how unrealistic it would be to have every person in every team covering everything in the backlog equally well. As this was never our short-term intention, I used the illustration below to show that although we would love for a team collectively to take on features without being dependent on other teams, we acknowledged that most teams would continue to have different expertise which could be used to supplement each other.
Specifically, as shown below, the blue team would of course go for the blue features, but if the next blue feature was not important, we would rather have them spend more time delivering, reviewing or supporting an important feature outside of their capabilities and comfort zone than efficiently delivering something nobody wanted.
3.2 The green approach
First up was the design of the three new teams. The pool of people had already been chosen based on their capabilities and passion. Besides that, the only thing predetermined was the combination of Scrum Master and Product Owner, as we wanted those to complement each other and act like a coherent, local leadership team.
The RTE and I truly believed that the fastest and best design, as well as the biggest buy-in, would come from providing clear guidelines and letting the people self-organize. I provided these design criteria:
- Small with a maximum of 8, fully allocated, team members – excluding PO and SM.
- Belonging with at least 2 people in each represented location.
- Balanced in terms of technical skills, work experience and ART seniority.
- Cross-functional with all team members collectively having all the skills required to define, build, test, deploy and operate.
The workshop agenda:
- Find your business card, add your main skills and a fun fact about yourself.
- Move your business card to the team where you expect to be able to contribute the most based on the people already there. If you are the first to go, you may base it on your relations with the PO or SM.
- Join the Teams call with your new, temporary team.
- Self-assess whether your current team constellation meets the design criteria. If there are any gaps, please state which gaps you currently have.
- Once the timer runs out, return to the main room for evaluation.
Once back in the main room, they collectively assessed whether the current distribution of people across teams was optimal. As that turned out not to be the case, I highlighted the gaps and encouraged anyone to either move their business card, if they could see a way for them to close the gap without creating a new one, or call out any other opportunity they had identified which involved someone else.
A few people moved, which solved most of our gaps. Following that, they revisited their open positions and tried to fill the gaps, in the longer term, with either one of those or by adjusting which skills they were currently hiring for.
3.3 The purple approach
On the surface, the approach and design criteria were identical to before.
As we had 30 people to distribute instead of 12, I assessed that it would be too overwhelming and chaotic for them to start completely from scratch. For that reason, I suggested a first draft that met the design criteria, for everyone to criticize and iterate upon.
A lot of challenges were raised, which would not have been caught by neither the ART Leadership team nor the design criteria. However, the suggested solutions seemed to focus mainly on getting more people (possibly caused by the underlying misconception that their scope would stay the same). As I ran out of time, we had to continue the next morning.
Generally, there was a lot of dissatisfaction around the many people being moved to the green teams, so in the morning I reframed the challenge with more clear boundaries.
They were told that they could not change the team design criteria, the number of teams nor the pool of people – but everything else was up to them. Additionally, I made and highlighted the suggested changes to the first draft.
This meant some of the design criteria were now broken, so without telling them how to solve this, I communicated the problems to solve.
This resulted in some suggestions, but it was apparent that there was not as much buy-in as I would have wanted and expected. It particularly became clear when a participant in pure frustration said that if ART Leadership wanted to dictate how the teams should be organized, then they could at the very least stop calling it self-organizing. I was very much set back by this, as our intention and communication had since the very beginning been to empower the people to form the best teams, but that was not how it had been perceived.
Because of this, I adjusted our approach for a third session with the purple teams. Instead of having the draft in a static PowerPoint, everything was moved to an interactive Miro board. Further, instead of providing a suggestion, I purely presented the old teams and highlighted which people were already moved. Also, I reduced the design criteria to a minimum.
This finally resulted in a team composition people could commit to, but not until they were promised a retrospective in the middle of the following PI to address any immediate issues with the new setup, and to see this as a first step towards continuously improving our ways of working. The result was worse than I had hoped for, but seeing as everyone was mentally exhausted from having spent almost the entire IP sprint with everything up in the air, we decided to be a bit more pragmatic for now.
As the teams were now fixed, I wanted them to create a new identity to mentally start from scratch and not get restricted to specific applications. This was done by choosing a shared theme and individual team names within that theme.
Finally, the workshops ended with each of the teams determining whatever they would need to get in place before the upcoming PI Planning, and what could wait for later.
4. What We Learned
Looking back at the benefit hypotheses, I find that
- We are now much better at executing our strategy and larger initiatives due to the shared program backlog, along with a shared Definition of Ready and Definition of Done.
- We have better throughput and fewer production issues due to fewer handoffs as teams have the needed skills to finish everything by themselves.
- We have established a foundation for T-shaped profiles, but only a few people have so far dared to try something outside of their specialty, partially due to a lot of need for application support. We are currently using mob programming to quickly establish new skills, team spirit and generally take people outside of their comfort zone.
- We have finally reduced our time-to-market with potentially releasable features, but still have a long way to go.
Besides the concerns already mentioned, there were some ongoing concerns from the different roles in the setup:
- PO concern 1: What about the stakeholders of my team? Are they okay with no longer having a specific team to go to anymore? How we addressed it: ART Leadership has been in touch with your stakeholders already, and although they have some of the same concerns, we will use radical transparency to solve their need for this going forward.
- PO concern 2: How will I prioritize things for people whose technical skills I know little about? How we addressed it: Focus on the problem to solve for the customer, not the solution. If you state the problem clearly enough, the team will be able to determine how they can best help to solve it.
- SM concern 1: What if we end up with the same teams again? How we addressed it: Should that happen, then it has been a fairly cheap way of verifying our team composition. However, that is highly unlikely.
- SM concern 2: What about the relations between people? How we addressed it: If the design criteria are met no matter if a person goes to team A or B, then it is completely fine to let the relations determine where they end up. However, if we have to compromise on our ability to deliver value for you to sit with your friend, that is not something we will do.
- Team concern 1: I am highly specialized, how will I be able to contribute if I move teams? How we addressed it: The teams will be more focused on customer value than specialization going forward. ART Leadership believes you have high potential and they want to invest in your continued development.
- Team concern 2: What about our application responsibilities? Will the application continue to follow me? How we addressed it: We want to move work to teams, not individuals. Every application goes to the corresponding team and if there are any corner cases, you will plan a handover for the upcoming PI.
Besides the concerns, I facilitated a retrospective with these results:
- Challenge 1: Our communication tried to build on top of a foundation of agile knowledge, which turned out to simply not be there. How we would do it differently next time: Spend more time elaborating on the vision and the intentions behind the design criteria (what it means to be cross-functional and why we want it) and necessary beliefs of agility (we no longer focus on individuals, and we don’t care whether you use your specialty, or if you are fully utilized all the time).
- Challenge 2: A lot of concerns did not reach ART Leadership until it was too late. How we would do it differently next time: Utilize SMs and POs as local change agents, especially for people not physically present.
- Challenge 3: The transition was rushed to be ready for PI Planning, as we did not want to go another three months with a broken design. How we would do it differently next time: Take the time needed for people to come to terms with the change. This includes communication, getting to know each other in the new teams and addressing their questions and concerns along the way. If needed, only plan for the first part of the PI.
- Challenge 4: There was a clear perception of an A-team and a B-team because some people were chosen for the new and exciting future strategy. How we would do it differently next time: Address openly why those people have been chosen, and why the remaining people are equally important.
