Government change programmes necessitate a mixture of Agile and more traditional approaches held together by an MSP type framework. The programme that forms the basis of this case study could certainly be described in this way.
It comprised an MSP style Portfolio with Programmes, SROs, Programme Directors and a Programme Management, planned with 4 tranches of delivery across multiple projects.
This was overlaid by a Technology Workstream - also allowed by MSP - to ensure most dependencies are kept under a single structure. Within the Technology workstream we had agile scrum teams - which soon had to scale up to use SAFe. At last PI we counted over 30 teams - with over 400 resources.
It should be simple enough - Agile scrum teams with embedded product and service owners, projects grouped into programmes (Release Trains?) with Product Managers, all teams on the same cadence and with suitable infrastructure to support Continuous Deployment and Release on Demand.
However this workstream was within a complex Government programme and, as with most SAFe transformations, within an enterprise that was not yet aligned to the transformed organisational vision and it crossed programmes where some projects necessitated a more waterfall approach. (Eg Infrastructure roll out).
What did we learn?
Necessity of flat structure with no recrimination for mistakes
If there is a hierarchy structure within the Team level then scrum teams feel pressured to include too much within a PI plan. The plan quickly becomes undeliverable.
If developers are given an equal voice all through the process then product owners and business owners can make informed decisions which could reduce risks of delays and over promising to stakeholders.
Understanding of the longer term implications of tech debt would allow efficient repayment to be factored in.
Importance of the upfront work to support the Product Owners
In order for a product owner to come fully prepared for a successful PI a significant amount of upfront work should have been completed.
Within our scrum teams we had 3 UX Resources, Agile BAs, a Solution Architect and a Business Architect. Within pure SAFe these should be in shared services. Perhaps a compromise is to see them as part of the Product Owner organisation completing the analysis and design of all user stories to be considered in the following PI. Perhaps this team should run 1 PI ahead.
Vertical alignment of the Product and Solution owners is essential
The most challenging part of PI plans was their alignment with longer term portfolio level deliverables.
Communication of the priorities and roadmap from Solution owner, through Product manager to Product owner is essential to ensure the timely delivery of a coherent vision within budget.
Prioritisation by the Solution manager of epics must be fully understood by product managers in the context of what therefore must be delivered in that PI and consequently what has to be deprioritised.
3 month timeframe is not long enough for more complicated features with cross team dependencies
Although the scrum team have not committed to a delivery until agreed at PI planning, this is almost certainly not true for the business.
Business deliverables which necessitate significant operational changes might require longer term planning.
Some features require sequential work by different scrum teams and hence might need a longer time frame to plan efficiently.
An outline 6 or 9 month plan should be completed at PI Planning to mitigate this risk.
Scrum teams assigned to Release Trains could shift per PI depending on priorities.
Developing and replacing back end systems as well as enabling services and front end services mean that some scrum teams have multiple outbound dependencies on different teams.
The easiest way to solve this within SAFe requires solution level prioritisation of features by the solution owner.
The team supplying the dependent enabling stories for the highest priority feature should then, for that PI, be moved to the Release Train including the dependent teams. Release Trains might then change between PIs as priorities change.
Importance of weekly SoS and Change Impact Assessment
Weekly Scrum of Scrums were run over the whole Solution Train. In order to make this effective it had to be focussed with sufficient preparation ahead of the meeting.
A separate Impact Assessment was run prior to Scrum of Scrums with the RTE and Solution Train Lead. This enabled any proposed changes to team level PI Plans to be analysed for dependencies with affected product owners. Changes could be either approved or escalated to solution owners for prioritisation.
Approved and escalated changes to PI plans were communicated at Scrum of Scrums.
There will always be constraints within government but SAFe can succeed if the importance of the Product and Solution Owner and their organisation is understood.
Finally there are the changes that are needed outside technology. For these change to successfully remove constraints the involvement of the business and portoflio leadership is essential.
Business Change teams need to be aligned to the same cycle with their own Release Train driven by the priorities set by the Solution Owner.
Some roles that appear within an MSP Portfolio need to be reimagined within a Scaled Agile Portfolio, otherwise there are too many decision makers away from the empowered teams. Therefore there must be buy in to the approach at the highest level of the portfolio.
Feedback from teams must be allowed to flow up to shape decisions at the portfolio level.
댓글