SAFe is a fairly consistent framework and set of tools. Despite that there are a few important and interesting inconsistencies that transformations should be aware of.
This is based on one and a half years of implementing SAFe at a large software vendor.
The Role of the Project Manager
SAFe has no project manager. Yet most organisations have project managers. This challenge is of course nothing new to organisations adopting agile approaches. However large software vendors still have projects. For example the implementation of the software at a client. This is a project. It is a project for a client. It has a beginning and end date. It is not a product. It has no continuous flow.
SAFe tries to solve this with something called the Epic Owner. In this context, this artificial construct does not work. It could however, work in the context of “Guilds” where the Epic Owner is responsible for the Guild delivering the Epic.
So how does the project map onto a SAFe implementation? The implementation of the software at the client needs to be done separately to the core product development. If the project is implemented using DSDM then the time boxes of DSDM are synchronised with the Sprints of the core product development teams. In addition, The DSDM increments can be synchronised with SAFe’s Release Planning cycles. DSDM then deals with the actual rollout, cutover and benefits enablement at the client. SAFe does not cover this, it only covers release to a client / Potentially Shippable Product(PSI).
In addition, the project manager is very much at the mercy of the product managers and product owners to prioritise his work. He has all the responsibility yet no authority over core product development.
The SAFe Guidelines for measuring progress specifically “M3: Measuring Progress” are inconsistent to the approach. To be able to measure progress it is necessary to estimate most of the stories for all the features whilst allowing architecture to emerge. This requires considerable upfront effort, especially for Business Epics spanning many releases. Either you do just enough design up front (JEDUF) such as in DSDM’s Feasibility and Foundation phases or just don’t bother measuring progress at all.
This relates back to client projects. They will want to know how much, when and what before a contract is signed. So effort does need to be made up front to estimate the work. In this case use DSDM as the basis.
If you really want to measure progress from year to year, count the number of completed stories and the cycle / leadtime of defects and question resolution. The first needs to go up. The later down. Always use relative measures, never absolute. Just remember, if the teams “game” the system by creating smaller stories to reach their goal, this is good! Why? Because the smaller the story the more effective and efficient the teams will be.
Planning Boards & Features
The deliverable of Release Planning is the planning board for the next release. If this only contains Features, which cover multiple sprints (even releases), where do we put the Feature? In the sprint it starts in or ends in. Worse, is it really done, or are just the stories that implement the MVP done? What about the remaining stories?
Are you considering SAFe?
Want to know more about our experiences? If so, then contact us. We’ll be more than happy to hear from you.