Consistent Velocity but Increasing Feature Cycle Time – How to Analyze and Improve Flow at ART Level?
Although the team’s sprint velocity appears consistent, the feature cycle time is increasing. WIP limits cannot be enforced, dependencies are unclear, and integration issues are arising with other teams within the ART.
Questions:
- How would you analyze this situation?
- What steps would you recommend to improve the team’s flow?
- How would you ensure coordination at the ART level?
Think about the commitments people make so empiricism can be established and maintained, and complexity thereby managed.
For example, each Sprint, are the Developers producing a Done Increment of immediate usable quality that meets a Sprint Goal?
In fact this question belongs more to Scaled Agile website then here, considering that many people at scrum org are skeptical about SAFe to say the least. Having said this I guess it is Release train engineer and System Architect who have to ensure synchronization in SAFe?
Let's look at this from a Scrum point of view.
My first question would be why is WIP not enforceable? Are too many items being started in parallel, due to org. pressure? WIP are very basic - build a culture of finishing work before starting new items.
But from what you described, the main problems were identified as unclear dependencies and late integration, which are likely driving up the cycle time. These two issues reinforce each other: when dependencies are not visible, they are discovered too late, causing delays and rework. If integration only happens at the end, issues accumulate and delivery slows further.
These are common signs of teams working in isolation, and also in a team, the team working in silos, i.e. Dev and QA operate seperately and QA coming in at the end of the delivery process.
Make dependencies visible early through cross-team discussions and even program-level planning. Scrum of Scrums or Nexus-style integration teams are example structures, but the exact method matters less than ensuring teams actually talk to one another. Integration also needs to shift left — integrating earlier and start testing earlier, ideally with automation, so that feedback and fixes happen continuously instead of being left until the end.
The overall goal is to move away from focusing only on single team velocity. Getting teams to communicate, find and discuss dependencies. Then integrate and test (new code) earlier, as often as possible, preferable having automation integration tests running on all integrations, i.e. a CI/CD pipeline.