Preparing for Team Self-Selection with SAFe & Structuring the ART

When it came to the shape of the squads, the feature vs. component team debate raged on and on. I was advocating features teams with a mix of people from all the disciplines in the department but not everyone agreed with the approach.  The Campaign Innovation teams had recently adopted kanban, resulting in amazing improvements in throughput. This meant that there was some reluctance to make any change that might negatively impact their new operating rhythm and associated productivity. The Capability Development teams were concerned about the technical debt in the existing environment and felt the only way it could be addressed was through a component team 100% focused on clean up. It was beginning to feel like the train was going to use the existing component based teams, and the opportunity to create true feature teams would be forgone, at least in the short term. I was not a happy camper.

SAFe has always taken a very pragmatic view on the Scrum Master role, acknowledging it might be too large an ask for an organisation new to agile to put a dedicated Scrum Master on every team on a new train.  This is certainly consistent with my experience. However, I am not a fan of one Scrum Master across two teams, especially if the organisation is using SAFe. I have found that if the Scrum Master has two teams it is only a matter of time before the Scrum Master decides to combine a retrospective or some other team ceremony because they can't be in two places at once. From there it is a slippery slope that can easily result in two teams becoming one very large team and in my experience large teams quite simply do not work.

My other concern with the shared Scrum Master model is logistical. How can a Scrum Master facilitate two teams during PI Planning, or any other ceremony on a synchronized cadence? What I can live with and support is a Scrum Master that also has a secondary role or skill-set and splits their time roughly 50/50 between Scrum Master duties and contributing to the team’s objectives in other ways.  This was the approach we took for the three additional Scrum Masters needed for the A&I Agile Release Train. This meant we would need three more Scrum Masters, so we decided we would identify them through the self selection process.

That left the Product Owner challenge. The original plan had been to use the leadership team as Product Owners. Saurav and I were not keen on this but these things are of course a question of balance. While managers as Product Owners concerned me, managers with nothing to do concerned me even more. The last thing we wanted was idle managers meddling in the squads because they had nothing else to do!

I had already planted the seed about functional managers being Chapter Leads, as per the Spotify model and after some discussion and consideration this concept was adopted. I was pleased with this as it addressed my concern about idle managers but we still needed to solve for product ownership. We talked about the option of using the Feature Owner model that I have found to be useful in the past. This concept resonated but it was not a slam dunk. There were concerns that leaving the squads and their business stakeholders "unsupervised" would lead to less than optimal solutions.

This led to a conversation about how we could ensure the squads delivered the "right" solutions. This particular organisation had a strong desire to be "analytics lead". And there it was, the answer was right in front of us - use the senior Analytics people as Product Owners. They were ideally placed to work with stakeholders on defining the analytical problem to be solved and to help the teams shape the right solution.

With the approach to the specialist roles and support teams determined, it was time to turn our attention back to the component vs. feature team debate. I fought a good fight but in the end, against my better judgement, we compromised. The first compromise was with the Campaign Innovation (CI) team. The CI people would participate in the self-selection, they would join squads and collocate with their new team, but 80% of their work would come from the CI kanban wall and there would continue to be a daily stand up for the CI Chapter. A similar outcome was reached for the Capability Development (CD) teams. Each squad would allocate 15% of their capacity to CD specific Technical Debt and there would be a daily chapter stand up. So while the teams might look like feature teams on paper there was a strong component flavour to the initial operating model.

The good new was that with the in principle agreement to partial integration of CI and CD into the squads we now had a model to take into the self-selection event. Our goal would be to form six evenly matched feature teams. We would include the interns and the four offshore developers working on a key campaign database. This meant we could have six squads of eight or nine people, with a Scrum Master, a Product Owner and two team members from each discipline.

That left just one role unaccounted for - the Release Train Engineer. Despite this role being absolutely critical to the success of the Agile Release Train, it took quite some time to land on a model for this particular ART. The approach they chose was roughly modelled on the dual RTE approach used by the EDW Agile Release Train. They would effectively have an RTE team, where the lead RTE would be supported by both an inwards focused and outwards focused RTE.

The final step in our preparations was marrying up Product Owners with features. Due to the shape of the work and some planned leave, we ended up with three members of the leadership team and three Advanced Analysts as Product Owners. While I was uncomfortable with the manager as Product Owner model, at least we had a way forward, that we could learn from and adapt over time if it was not working.

With one week to go until the self selection event, things were feeling somewhat under control. We had a copy of Sandy & Dave’s book and we had downloaded their Self-Selection kit as a guide.  We had a venue booked, we had agreed the constraints for the squads, we had written up the FAQs and we had a plan to ensure there were photographs of every who would be on the train to use in the event. All we needed to do was get the newly anointed Product Owners up to speed on their features and prepared to talk to them at the self-selection event and we would be all systems go.