De-scaling your agile
•Download as PPTX, PDF•
1 like•455 views
scaling your agile is only half of the problem
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
De-scaling your agile
- 1. Scrum team No scale Scaling Complex Simple Current state Target state Unstructured experimentation dogmatic framework adoption
- 2. Scrum team No scale PHASE 2: Scaled PHASE 1: Scaling Risk: Scaling anti-pattern Risk: Framework as an end state risk Complex Simple Current state Target state
- 3. Scrum team No scale Scaled PHASE 3: De-scaling Scaling anti-pattern risks Framework as an end state risk Complex Simple Current state Target state 1. Simplify architecture 2. Change org structures 3. Introduce new ways of working PHASE 1: Scaling
- 4. Scrum team No scale Scrum team Scrum team Scrum team De-scaled Scaling anti-pattern risks Framework as an end state risk Autonomy without alignment risks Complex Simple Current state Target state 1. Simplify architecture 2. Change org structures 3. Introduce new ways of working PHASE 2: Scaled PHASE 1: Scaling PHASE 3: De-scaling
Editor's Notes
- Phase 1. the decision to scale your agile At some point someone says it is a good idea to build a scaled agile model. If this is taking place in an organisation with a number of legacy applications (monoliths) then people start to create new and unique ways to adapt scrum-like frameworks for at-scale implementation. This usually results in an agile at scale framework (SAFe, LeSS, Nexus) being chosen as a target state for the org’s agile way of working. During phase the risks of scaling agile become apparent; namely people start experimenting without any coordination (chaos) or dogmatically adopt a framework without consideration of the context of the org.
- Phase 2: Scaled As the scale in number of agile teams grows problems with coordination, alignment, business engagement/involvement, releasing and operating working software all become exposed and have to be resolved. Problems at scale move from being complicated to complex and often the scaling framework has to help guide the org on how to implement for such complexity BUT… a good framework does more than that. A good framework “perturbs” the current state and challenge the org to keep simplifying its structures and architecture and ways of working toward a simplified target state. To get to this target state a de-scaling phase has to be undertaken. (see PHASE 3.)
- Phase 3: de-scaling To de-scale the org needs to simply its architecture, organisational structures and introduce new agile ways of working. De-scaling involves stopping doing scaled agile ceremonies and replacing them with the basics as teams become more autonomous; no longer needing elaborate alignment and coordination practice associated with scaled agile frameworks. De-coupling dependencies, further simplifying practices and having removed most boundaries between business and IT folk.
- De-scale organisations have fully autonomous teams each with there own way of working (post-framework); they are high-performing software teams continuously delivering business value in a steady and predictable manner. They can “turn on a dime for a dime” I recently visited an organisation in Melbourne that had successfully de-scaled itself. They wanted solutions to different problems; they had lost alignment and had little transparency across their 50 teams. Everyone seemed happy but had no common vision. Running cross-team projects was near impossible. So the risk of misaligned autonomy needs to be mitigated through maintaining guilds and communities of practice as well as minimal transparency reporting.