The WaterfallDoes SAFe permit you to continue running a dysfunctional Waterfall? The classic "Water-Scrum-Fall", a widely spread phenomenon:
|The Water-Scrum-Fall: "Agile" is something else.|
Can you do that with SAFe? Yes. Then again, you'll be hard-pressed to find any type of statement that SAFe is actually encouraging this. So - why do people think SAFe is just Waterfall reloaded?
1. The PI Planning
As described in another article, the reason why there is a "PI Planning" is not to maintain the Plan->Build->Run cycle (aka. "Waterfall"), it is to create common understanding. PI Planning does not separate "planners" and "doers": Given a prioritized list of abstract, high-level stories ("features"), they decide autonomously what to do while exploring the "Why" together with others. The detailed "What" and "How" is deferred to the latest possible time where it makes sense - i.e. the Iteration (Sprint) Planning of the iteration when teams actually get around to the topic.
Highly empowered, autonomous teams make their own decisions regarding "What", "When" and "How". Managers serve as facilitators, not as authors. Teams propose the most feasible ideas. Teams agree with each other on the objectives. The output is a prioritized, value-based list of objectives for the overall PI - and an intitial short-term backlog for each team. Everyone knows full well that the backlogs can and will change, both in content - and in order. The teams commit to work towards common goals, not to complete specific activities.
PI Planning can not be compared at all with classic project planning.
2. Three-month increment
3. Systems TeamA specific team deploying and operating the built product ("Operations") is a common pattern in Waterfall organizations. The consequence is a "throw over the fence" attitude ("works on my machine") and animosity between developers and operations.
SAFe strongly encourages DevOps practices, bringing the responsibility for operations directly into the teams. The buzzphrase "You build it, you run it" is also applicable in SAFe. Throwing stuff over the fence is not encouraged, as this creates communication gaps and a desync between work in progress among teams.
Then - what is the purose of the Systems Team?
Teams are potentially challenged to provide a well-working delivery infrastructure, such as deployment pipeline and operating environment.
Especially early on in a transition, it makes more sense to have specific experts deal with infrastructure so that development teams can get around to deliver value and not constantly be distracted by working on base technology. As the Agile Release Train (ART) matures, the infrastructure stabilizes and the amount of maintenance work should decrease to a point where teams can handle it.
Although this should not happen, occasionally developers or large systems are so focused on their work that they lose sight of the overall process. The question "Who maintains the Big Picture?" sometimes remains un-answered. In cases where developers work on individual microservices and lose sight of the end to end customer facing processes, there needs to be someone to ensure that the customer can actually use the new increment. This may require both exploring the product and automating standard test scenarios. Similar to the point above, as the ART matures, the amount of necessary manual oversight and undone test coverage should approach zero.
Long story short: The Systems Team is not doing work in a different phase. They do work that is outside the other teams' Definition of Done.