Preparing for Self-Selection with SAFe & Structuring the ART

Em Campbell-Pretty
Dec 14, 2016

Updated 6 February 2024 to reflect SAFe 6.0 terminology

creating great teams

Those who know me will not be at all surprised to learn the first thing I did once there was agreement to use self-selection was buy and read Sandy Mamoli's book Creating Great Teams: How Self-Selection Lets People Excel. I had heard Sandy talk on the topic some time back, and my colleague had previously used the technique with Andy Kelk, so I wasn't walking in blind.  My experiences with watching people bastardising SAFe made me want to stick as closely to Sandy's guidance as possible. Specifically, we chose to keep the number of constraints to the absolute minimum. In hindsight, I may have been a little naive on this front, but more on that later.

With the approval to proceed with self-selection in place, conversations about the teams on the train changed from who was in which team to what shape the teams should be and what mission each team should have. There were two notable exceptions - the Pipeline team and the System team. In both cases, the team members were allocated as opposed to being given the opportunity to self-select a team to join. Initially, this made me a little uncomfortable, but after checking in with some of the impacted parties, it seemed that they were expecting to be in either the pipeline or system team and were comfortable with their lot in this regard.

When it came to the shape of the squads, the feature vs. component team debate raged on and on. I was advocating for stream-aligned 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 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. They felt the only way it could be addressed was through a component team 100% focused on cleanup. It was beginning to feel like the train was going to use the existing component-based structure, and the opportunity to create stream-aligned teams would be forgone, at least in the short term. I was not a happy camper.

The other challenge we needed to face was filling the specialist roles of Scrum Master and Product Owner. Based on the size of the organisation and my insistence that teams should be no larger than nine people (including the Scrum Master and Product Owner), it seemed likely we would have six delivery teams. Therefore, we would need six Scrum Masters. Prior to my involvement, an assumption had been made that one Scrum Master for every two teams would be sufficient. This resulted in there being only three full-time Scrum Masters available for the train.

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. (Update: These days, we suggest a 70/30 split where the 70% is for Scrum Mastery.)

That left the Product Owner challenge. The original plan was to use the leadership team as Product Owners. We 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, which I had found to be helpful 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 judgment, 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 news 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 steam-aligned 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.

ART Design Strawman
Proposed Agile Release Train structure

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 didn't work.

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 downloaded their Self-Selection kit as a guide.  We had a venue booked, we had agreed on the constraints for the squads, we had written up the FAQs, and we had a plan to ensure there were photographs of everyone 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 prepare to talk to them at the self-selection event, and we would be all systems go.

Check out Part 3 in this blog series, Facilitating Team Self-Selection for a SAFe Agile Release Train

Back to Top

Subscribe to Newsletter