Preparing for Team Self-Selection with SAFe & Structuring the ART
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 as the approach to forming teams for the A&I Agile Release Train 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 +Mark Richards had previously used the technique with +Andy Kelk at Australia Post, so I wasn’t walking in blind. My experiences with watching people bastardising SAFe made me want try and stick as closely to Sandy’s guidance as possible. Specifically we chose to keep the number of constraints placed on the teams 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 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.
The other challenge we needed to face into 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 and therefore we would need six Scrum Masters. Early on an assumption had been made that one Scrum Master for every two teams would be sufficient. This had resulted in there being only three full time Scrum Masters available to 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.
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.
|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 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.
Check out Part 3 in this blog series Facilitating Team Self-Selection for a SAFe Agile Release TrainTweet