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 Train
When an organisation introduces agile, it is not uncommon for there to be a mass rollout of Agile Fundamentals training, where the role of the Product Owner is positioned as being an empowered business person who is colocated with and 100% dedicated to work with the agile team. This sounds wonderful in theory, but when we start to scale this begins to get tricky.
I once worked for an organisation that had a policy whereby you were only allowed to run your project agile if the business made a product owner 80% available to the project. Of course, the business wasn’t silly, they knew how to get around this constraint - either find someone in their department who isn’t adding a whole lot of value and allocate them to support the agile team or hire a contractor off the street and have them fill the role of Agile Product Owner. Problem solved!
As we begin to scale agile, the pressure on the business to provide more and more product owners exacerbates the situation. As much as we might want it to be the case, most businesses don’t have a small army of people just waiting for a scrum team to come and adopt them. The Scaled Agile Framework (SAFe) has historically attempted to address this capacity constraint by allocating members of the development organisation to the product owner role and adding the role of the Product Manager, who reports into the business and is effectively the product owner for the Agile Release Train (ART), the team of agile teams. In SAFe the Product Management is also empowered to ensure the dedicated ART budget is being invested in the right features.
As someone who has been the business sponsor of a large agile program, I am very familiar with how challenging it can be to source enough business product owners to support multiple agile teams. In the beginning, I opted for the “contractor off the street” solution. Well, that is a slight exaggeration - most of the contractors were not exactly off the street and were at least somewhat familiar with the solution context, but still not true business people. Regardless, the fact that these product owners reported to me as the business sponsor did give me a sense of comfort.
As ingenious as I felt my approach was, it was not the right solution. These proxy product owners caused all sorts of challenges for the delivery teams. They just didn’t have the in-depth business knowledge required to support the agile teams on a day to day basis. So when I first came across SAFe’s product owner model in Dean Leffingwell's Agile Software Requirements, Product Owners reporting into development felt like an even bigger compromise than the approach I already had in place.
I knew what we needed was real business people. I also knew the business units were never going to be willing to dedicate the right people to working with the agile teams. So why not ask the business for something they can give…a Feature Owner. Yes, yes, I know there is no such thing as a Feature Owner, so bear with me a moment while I explain...
You see SAFe has a requirements hierarchy whereby our largest requirements are epics, which are broken down into features, which are broken down again into stories for delivery by the agile teams. The ARTs deliver features and features have business benefits. So rather than attaching the content authority to the ART in the form of a Product Manager or the team in the form of the Product Owner, why not have a content authority for each feature in the form of a Feature Owner?
Unlike a product owner, we didn’t expect Feature Owners to be 80-100% dedicated to a single agile team. Instead, we expected them to be available to the team(s) 4-5 hours a week, every week that their feature is being worked on. The idea was to ask the business for something that they have the ability to give. Almost anyone can find 4-5 hours a week for a month or two to contribute to getting a good quality outcome on a project that they care about. As a rule I have found that once the Feature Owner and the Agile Team have established a relationship, a human connection, then the arrangement changes from a number of hours a week to all parties collaborating to contribute whatever time is necessary for successful delivery of the feature. From the teams’ perspective the Feature Owner is the ultimate authority and single voice of the customer on the scope and acceptance of the feature.
Over the years since I first used this model, I have found many other ARTs have facing similar challenges with respect to the availability of business product owners and the allocation of dedicated ART budgets. The feature owner model has often come in handy in these situations. Sometimes the Feature Owner is more like a Product Owner for a specific feature, collocated with the team and able to provide a large proportion of their time to the team while their feature is being developed. In other scenarios, the Feature Owner is supported by a product owner who is a member of the agile team. When working with ARTs in the Digital domain, the role of Feature Owner has often been played by someone from the business unit funding the feature, while someone from the channel team plays product owner. This enables the commercial decisions regarding scope to be retained by the funding business unit while still enabling those responsible for the channel’s customer experience to ensure consistency. In some cases, I have used this model to augment the technical product owner as advocated in SAFe.
One of the most common concerns people raise about this model is the impact of multiple features owners on the agile team. When applying the Feature Owner model within SAFe, we need to ensure that we have also provided the teams on the train with a force ranked, WSJF prioritised backlog, so there is never any doubt about the priorities of the features being delivered by each team. Limiting feature WIP can also help minimise any confusion or competing priorities caused by multiple feature owners working with a single agile team.
You may have noticed that the introduction of the Feature Owner role, does not address the role of the Product Manager. In a world in which the ART has it's own budget, the function of Product Management probably wouldn't change much. However, if your ART is project funded this gets a little more complicated. One of two models tend to apply in this situation. Either the Product Manager is the business owner of the ART (common in the digital domain where the business may have a nominated channel owner) or perhaps there is no Product Manager at all. How to run an ART without a Product Manger - is beyond the scope of this blog post, but something I promise to provide guidance on in a future blog post.
So, while technically, there is no such thing as a Feature Owner, perhaps there is a place for such a role in some circumstances. In my experience appointing a Feature Owner provides a pragmatic solution to some of the challenges we face when Scaling Agile. In most cases, it does not replace the need for each team to have a product owner, instead the addition of the Feature Owner augments the Product Owner and strengthens the connection between the business and the agile teams. I like to think of the Feature Owner model as prioritising access to the right people over more access to the wrong people.
Pretty Agile® and Tribal Unity® are registered trademarks of Pretty Agile Pty Ltd.