Scaled Agile Framework
When scrum is no longer sufficient
Scrum is highly effective to manage a team of knowledge workers. It delivers on the promise to increase knowledge worker productivity (efficiency) and effectiveness. A typical Agile team consists of ±7 people. So if you are running big projects and one team would take too long to deliver what you need, then you will inevitably need to work with multiple teams in parallel. Scrum does not formally prescribe how to scale to multiple teams, markets and deal with larger portfolios. This is where SAFe comes into play. There are several other models and publications about the subject of scaling. None of them have really taken off as SAFe has done now. Jeff Sutherland and Ken Schwaber have both published excellent papers on how they scaled Agile in larger environments. Yet there has not been a formalized framework to guide large enterprises in implement-ing agility and portfolio management at scale. Arguably this is due to the risk of such formalizing efforts: the risk of the method becoming leading over situational problem solving. This is the Agile anti-pattern of method-over-result.
What is SAFe?
What does the framework consist of? It is a collection of proven Agile practices, divided over strategic (called Portfolio), tactical (called Program) and operational (called Team) levels. This division resonates better with business executives than Agile terms like ‘Themes’, ‘Epics’ and ‘User Stories’. Scaled Agile effectively connects portfolio man-agement towards program roadmaps and dividing the work over multiple Scrum teams. There is a prominent place for architecture and it helps to balance deliberate architecture (or predesigned) and emergent architecture (or evolving). Although architecture is gen-erally considered to be emergent in Agile, large scale development efforts need (some) predesigned architecture to ensure architectural consistency. This enables integration and minimizes rework due to incompatibility (refactoring)
There are three scaling dimensions where Scrum in itself is no longer sufficient and applying Scaled Agile practices can help to solve specific issues that arise from scaling up Agile (see figure).
Bitatio atus blabo
Nost iamsegi aleris
Risks of SAFe heavy
‘One size fits all’ syndrome
To apply all the Scaled Agile practices towards teams that do not need them. Projects that are big in importance (high value) but only have 2 Scrum teams probably do not need a System Team to manage the development environments. Or a Release Engineer to organize the work across sprints towards a release.
‘Artificial H.I.P. sprint’ syndrome
When the hardening of sprint outcome is allowed in a separate sprint (the HIP sprint, see terminology guide) it will inevitably lead to teams slacking towards sprint goals. Hardening will come later.
‘Innovate now!’ syndrome
Innovation and having novel ideas can in general not be planned for. Therefore it does not make sense to have Inno- vation sprints at given times. The ability to innovate should be ongoing and built into the process.