Here at Travelport, we are going through a product, process, people, and technology transformation to be fully agile via SAFe (Scaled Agile Framework). I was fortunate to be offered some early training around what this means for product management, and how we interact with delivery in the new world. This blog is a summary of the Agility-squared 4 hour condensed training.
Scaled Agile is all about trying to maintain the principles of agile at scale, and is used effectively by many large organizations. Much of the framework around SAFe came organically from the field, from large organizations that have implemented a variation of agile previously. So in other words – it’s a compendium of trial and error that is constantly evolving as new data emerges. You can read some of the case studies on companies that have embraced it here.
One of the core components of Agility-squared is the concept of an Agile Release Train (ART). It consists of multiple teams, typically across Lines of Businesses at the Program layer. Product management owns the Epic backlog to prioritize what the teams within the ART work on. The ART team plans in program increments of 4-6 sprints in a team of teams mentality, planning in a 2 day period every cycle. In this program increment planning, product management brings a prioritized list of features and the vision that gets shared with the team. First half of the first day is dedicated to the vision. Then, it moves in to a team working session where the prioritized features are then broken down, some high level design is done, and come up with their draft plan of what of this work can be done in the next Program Increment (PI). At the end of the first day, management takes a look to see if this is good enough for the next PI, and then make some minor adjustments if the plan the teams come up with aren’t sufficient. An input to this planning would be the capability leaders getting together at the Solution Layer to rack and stack jointly their individual WSJFs (Weight Shortest job First).
At the Solutions layer, the scrum of scrum-masters is called the Solution Train engineer. At the program layer, there’s a Program Train scrum-master called the Release Train Engineer. Both of these roles contain facilitation tasks, planning tasks, and dependency tasks (inter-team dependencies) at their respective layers. They also help empower the teams to be on of a self-managing ethos.
Here’s a look at the layers:
How can product management help in the agile transformation? Product management is at the focal point between the customer needs and the delivery teams, making sure the team delivers the right thing and that the development teams are doing it correctly. With a sound vision, the development team always has a reminder of where they’re going – and as such the product manager maintains and drives the “Why.”
The responsibilities of Product Management in an ART is around understanding your customer needs and validating solutions, as well as defining features and non-functional requirements (NFRs). The Product Manager should drive customer interactions around key milestones of definition as well as design reviews to get quick feedback back to the team. The NFRs can be high-level guidelines from the product manager that are made more granular, relevant, and applicable to the technology stack by the solutions engineer. The Solutions Engineer should be available to help the Product Manager understand what’s feasible and what should be considered when product writes NFRs.
How are features and enabler prioritized in agile? Using a methodology called Weighted Shortest Job First (WSJFs), pragmatic prioritization can be accomplished looking at the metric of cost of delay. In order to determine which job to do first, we find out the cost of delay divided by the size of the effort. Features with the highest WSJF should have the highest priority. The Cost of the Delay = User/Business Value + Time Criticality + Risk Reduction/Opportunity Enablement. These. This should be done at each layer in the SAFe hierarchy to make prioritization decisions – at the team layer, at the program layer, at the solutions layer, and at the enterprise layer. If you’re facing budget cuts for example at the solutions layer, you should do WSJF across your initiatives to help decide what to invest in and what to cut.
This usually works the best across a smaller set of features, around 10 or less, but can also be done at scale. One thing I am struggling with, at the portfolio level, is looking across 100s of features to prioritize them. A suggestion from the class is to just start with the numerator and tackle the first 20 of those to go work with the team to get the denominator. Note on the Job Size – this should NOT be time, it should be using the Fibonacci sequence based on relative weighting just like the other factors. The Fibonacci number can be used more than once, as two items could have the same relative ranking against a dimension.
Another way to help organize thoughts around prioritization is user story mapping – where you list all the functions a customer could perform vertically, and then the flow and the features needed to accomplish that function horizontally, and you move from left to right in terms of what the customer would do.
At the end of a Program Increment, you may or may not put the feature in to production – it’s up to the business to decide if enough value have been accrued to do a release. There’s also the potential to release to product, but not do any go to market (GTM) activities and essentially keep the feature dormant until it is ready to be formally launched.
What are the metrics around measuring success during an agile transformation?
- Speed to market – feature to market (definition to delivery to market) so that it’s usable by your customer base (this is the definition of done)
- Cost to deliver and ROI
- Net Promoter Score
And, here are some nitty-gritty guidelines as we build our layers and our teams:
- 50-125 people on a train, a typical agile team has 5-9 people, so that means about 10 teams on a release train.
- At a minimum, 20% of the team’s velocity should be spent refactoring tech debt, refining best practices, learning and improving the process etc.
Finally, some of the key reasons why agile transformations fail can include:
- Leadership team doesn’t embrace it and shift the way they manage resources in agile teams to support the agile ethos – this can lead to measuring and rewarding the wrong things
- Lack of decision making based on an enterprise view
- Not identifying where the true value lies for the enterprise
- Too much work in process without focus
- Teams to not have all the required, dedicated roles to fulfill delivery commitments
- Annual funding process does not align with agile (quarterly)
- Too much manual effort in our delivery processes
- Low accountability in key roles
- Insufficient authority in delivery teams to be able to make and keep commitments
What to do next? Nothing better than diving in immediately. See what works and what doesn’t and tailor this to your organization and team culture. Trial and error is the name of the game, and comfort and intuition will come to the team over time.
Good luck!