Many organizations try agile projects with fixed scope budgets, which is a contradiction. Design workshops are followed by scrum sprints to build the application. Many of these projects are missing key agile values like customer collaboration and people interaction. The ultimate goal of scaled agile is to to get things moving, fast, while keeping a long-term vision.
The diagram below depicts a "false agility" development cycle in which every team tries to complete their project scope, with late changes and untested features that must somehow be merged with other projects. False agililty results in conflicts and lengthy delays.
Regardless of whether the project team implements this project using agile terminology (user stories, sprints always sound cool), the fact is that they follow a waterfall process, with time being the only non-fixed variable. These type of projects incur delays and intensive phases of Hypercare after the official Go-Live. False agility will wreak havoc in your release managemenet processes, which should focus on pre-scheduled deployment windows.
Here is a diagram that depicts these mechanisms in a 12-14 week major release cycle (e.g. a program increment).
From a program perspective, implementing a hardening sprint with a code freeze on all projects should be complemented with more granular, ongoing checks in order to integrate all the different streams.
We must develop on cadence and deliver on demand. From a project perspective, this diagram shows the buffer and the regular, ongoing checks will follow a cadence defined at the program level, typically by a Center of Excellence.
The basic principles are:
This ensures the deployment to production is smooth, there are no delays, and there is no massive post go live troubleshooting needed. The pending features will be completed later on in an orderly way. However, this implies that the full scope of some projects is not covered, which has implications (e.g. this goes against the SOW signed with the partner).
Program coordination is achieved via release planning workshops, which are a 2-day meeting where all project team leads plan the features they will try to implement in the following 10-12 weeks, and will map their inter-dependencies (if any) in order to better prioritize them.
This will be very important for Salesforce programs for a different reason: We as a platform have some key objects and features that must be defined for the entire org. This requires data governance for some of the key entities (accounts, contacts, etc). In Salesforce programs, this release planning will be mainly used to align on shared components, such as defining an account trigger that implements different logic for several record types belonging each to a different app.
Adolfo Magan is a Master Enterprise Architect at Salesforce. For over 20 years he has been helping align Business and IT strategies by defining the right operating model and by crafting a roadmap for digital transformation. In 2000 he co-founded with 5 colleagues a consulting start-up company in Los Angeles, CA bringing it to a multimillion dollar business-later acquired by an international group which went public in Nasdaq in 2010.
You can connect with Adolfo Magan on LinkedIn