Want a supercharged ART? Don't settle for a Proxy Product Manager!

In a recent SPC class, we wound up in a very interesting discussion about the role of the RTE and the potential need for multiple RTE’s. Given that in our very first Release Train we had employed a “paired RTE” approach (described here by my colleague Em Campbell-Pretty), we had a fairly public opening position on the discussion. I have a client who has a rotational RTE system where each train has 2 RTE’s. One leads execution of the current PI, and the other focuses on preparation for the next. We’ve also seen and heard of numerous other variations. As the discussion progressed, something crystallized for me. In every single case where it’s been necessary, the Product Management function has either been weak/uncommitted or fulfilled in proxy by the IT organisation!

One of the great strengths of +Dean Leffingwell’s approach to defining SAFe has been his pragmatism. One example of this has been his historical approach to defining the type of people (traditional role descriptions) who might fulfill a SAFe role. As with the entire framework, he distills and documents ‘observed patterns’ rather than theory. I vividly remember a moment of shock and horror when I saw that he had listed “BA’s” as potential product managers. Whilst having acknowledged the occasional need to utilise “IT proxy” product owners, the notion of a BA as Product Manager triggered the following email:

Hi Dean,

I'm teaching an SPC and just had the product manager slide onscreen and someone in the audience pulled up the guidance article and said this could be a BA.

After I fell off my chair I suggested someone must have applied the content to the wrong article (ie meant product owner). Are you able to confirm I was right and someone hasn't started smoking strange drugs?

In typical Dean style he reminded me that many organisations have extremely senior strategic BA’s who could well fulfill the role – which got me thinking about a couple of BCG BA’s I had worked with and resulted in a humble apology.

The drawback, however, is that where Dean describes something that “can work in particular contexts”, it is all too common for organisations to interpret the guidance in unfortunate fashions – in this case implicit license to put an IT person in the role. This likelihood is inflated given that most large IT organisations have formed a “wedge division” of “business-facing IT” who act as interpreters and demand managers. The value proposition of such an organisation is threatened by the direct connection between business and developers underpinning agile and it desperately seeks survival .. “surely we are the logical product managers and owners!”

What Dean is looking for is someone who can fulfill the responsibilities and accountabilities of the role. So, what are they? A Product Manager is a person entrusted by the organisation with identifying the best mix of features and steering the optimal economic trade-offs between them to maximise the ROI on an investment of somewhere between $10M and $30M per year.

In recent months I’ve been fortunate enough to launch two Release Trains with not just exceptionally strong co-located business Product Managers but also dedicated co-located business Product Owners for every team. In both cases, they have matured further in a single PI than I have seen in many others across the course of 18 months. Following are some of my thoughts on the key differences:

• Agile is about eliminating the concept of “business and IT”. It’s about working together on a shared mission. It’s not about something “IT does to the business”. Proxies simply maintain the status quo wearing a slightly different disguise.
• The container of the system shapes the system being optimised. As long as the Release Train contains only IT, it will suffer from local optimisation with the relevant area of the business forming a separate system also locally optimising.
• Business people come with business networks. Whilst a short-lived team can source a product owner with deep domain knowledge, a long-lived team will over time work on features covering many domains – to survive the product manager and owners need to know how to bring the right subject matter experts to the table to provide the deep domain knowledge. This is far easier when you’re accessing your mobile phone contact list than researching an org chart!
• Business Product Managers/Owners know how to get the right people to the System Demos and demonstrate in business language about business outcomes being achieved.
• Business leaders bring more to the table than just content authority. They’ve also often received far more development in people leadership than their IT counterparts. Watching somebody bring their call centre team management experience to the table with dev teams is simply amazing. 
• Proxies will be proxies. They will naturally preserve their value proposition by acting as translators rather than connectors. 
• It’s very different when a business leader elects to defer something than when an IT leader asks a business leader to defer something!

Chatting to the executive sponsor during the second PI planning event for one of these trains recently, he shared that one of the things that particularly excited him was watching his business teams reach insights and form alignment at a business process level as they collaborated with the dev teams and their product owners in breaking down their features. He had a grin from ear to ear, but it wasn’t quite as big as the grin I was wearing the night before when I was forwarded an email from another train. It contained the following story:

Once upon a time there was a new Agile Release Train (ART) that had just finished its third sprint. Everyone was amazed at the velocity the teams had achieved. But at the retrospective 2 things became clear:

(1) the teams had worked long hours and many nights to achieve a higher velocity to overcome what they saw as a hump necessary to meet the desired business date for production after 2 more sprints.

(2) the teams were doing "wagile", coding in week 1, then testing in week 2.
The Product Manager thanked the team for their extra efforts, but told them, and - importantly - all the attendees at the showcase, that the velocity achieved was not sustainable, and long days and nights were not to be repeated.

The ART then reviewed the way the teams were working, and decided that extra attention needed to be paid to the adoption of Test Driven Development (TDD). The coach also refreshed the teams on how to conduct sprint planning for sustainable pace.

The Product Manager then told the teams to take as long as necessary to plan for the next sprint, including how to adopt TDD. With some further guidance from the Release Train Engineer (RTE) and Systems Team, the teams re-planned how they would work, as well as setting a more sustainable velocity target for sprint 4.

After I shot an email to the Product Manager saying “hey, can I please quote your story”, she regretfully informed me that she hadn’t been the author but had the following to add:

It was a tough decision knowing that maximum capability in the short term is what senior management are looking for, but also being aware the greater value lay in ensuring the team had the time and space to embed the practices and achieve a sustainable long term velocity and you know the saying, short term pain, long term gain.

On a closing note, my few weeks of pondering the topic have left me with a realization. We obsess about the critical role of the Release Train Engineer. At every gathering of SAFe people, discussions center around how to find, retain and avoid burning out great RTE’s. I think perhaps we’re guilty of spending too much effort on finding and growing RTE’s and not enough on Product Managers. In fact, I’d go so far as to say that in pursuit of great business outcomes and a thriving ART a great Product Manager can cover for a weak RTE far better than a great RTE can compensate for a weak Product Manager!