Agile principles are very easy to adopt and very difficult to follow entirely. For example the ongoing philosophy explaining why is it better to deliver just a few high-quality-tested-working-shippable features in two weeks; over tons of non-tested and arguably working items in three months to a manager who just promised the earth to the client… Or the never-ending resistance when evangelizing team-work and condemning story-per-person bad practice.
One particular instance has always bothered me too – how to scale Agile properly. Self-management, self-organization, quick and efficient decision making without higher authority work well in small teams (up to 7-9). Good examples are guerrilla squads – they are very efficient in utilizing terrain and other advantages against outnumbering opponent. It’s also true that armies (or large groups) cannot efficiently self-organize and self-manage – there is a good reason for the complex hierarchy in the army.
Recently, I was lucky to have been commissioned to review and summarize one of the most famous frameworks to scale Agile – SAFe and although the final overview document is huge I will try to summarize it even further in this post using three flags to categorize my points (good, not so good and ugly).
Here we go:
* SAFe is an interactive framework for implementing Agile practices at enterprise scale. It is marketed as an Agile solution for programs of only 50-100 people, and in enterprises employing thousands of software developers. The expected main benefits include: better alignment on all corp. levels, higher quality software and faster delivery to market.
* There are three levels of scale recognized
Portfolio – align programs to enterprise business strategy along Value Stream lines
Program – funding for personnel and other resources are provided and aligned to the enterprise mission. Agile Release Trains (ARTs) introduced and used to deliver value
Team – Part of Agile Release Train. Responsible for defining/building/testing/deploying user stories in sync with the other teams. Pretty much - the ordinary Scrum team
* SAFE introduces some new roles responsible for overall architecture, UX, coordination and product development, centralizing some of the authority and the decision making process inherent to the Waterfall practice (SAFe introduces a mix between Agile/Waterfall practices). The System architect and the UX person would really have big shoes to fill as a lot will depend on their decisions. The System team is also something new – responsible to integrate, test and demo the features just before release. The Release Train Engineer (RTE) is acting exactly as a chief Scrum master and is coordinating the work of many teams and the other roles accordingly.
* The most significant innovation in SAFe is probably the Agile release Train (ART) – a good scale of Agile software development allowing 5-10 different teams to work in sync on a specific ‘value stream’ (project, product, client or just Epic). The train is supposed to run in cycles and deliver value every 10 weeks. Optional releases could be done after each iteration end.
* A lot of the Agile mindset and some Scrum practices are followed. One example is that after each iteration the teams are expected to deliver fully tested / shippable and usable increment of software.
* The teams work in sync – using the same iteration length (including beginning and ending dates). I also noticed it is much better to organize dependent teams to work the same way in order to deliver potentially shippable increment at the end of each iteration.
* An example of a Waterfall practice would be the last HIP Phase/Sprint – reserved for integration, quality inspections, innovation and defects fixing. Currently the HIP phase is introduced by the necessity to stabilize the deliveries from the different teams, fix defects and refactor code. With the introduction of this phase the ability for premature deliveries is arguable.
* There will not be a huge impact for most of the Scrum teams as every team will be part of the Agile Release Train and mostly operate the way it currently does (in terms of Scrum practices). The noticeable difference will be that the team will need to take part additionally in the Release planning, Release demo and help Grooming Epics for the following Release planning… and God – those meetings are huge. Also depending on the implementation some of the integration / testing / demoing responsibilities might be stripped – and it does not sound like a good idea.
* Although undoubtedly an innovation - ART assembly will be somewhat tricky. Should ARTs be assembled by projects, products, or just a bunch of related features? It would be easier to break existing teams and interrupt their habits and well-established practices.
* All the new roles and teams will inherit the flows from the Waterfall/Centralized decision-making and management practice.
The System architect for example - would be in huge risk. It smells really bad to overburden one person with all the architectural decisions regarding a complex system. Mitigation would be to involve appropriate team-members from each team to help/support him.
On the other end the System team would really feel the pain integrating and releasing the work of the others. There is a good reason why this job is done by each responsible/delivering team in Scrum. Demoing should also be done by the appropriate team-members and not just by one separate team.
* Releases on demand outside the end of the ART cycle will arguably be possible with the introduction of the HIP phase (would not even call it a Sprint). SAFe proclaims that a release could be requested after each iteration (even after the first one), therefore in order for this to happen - the teams should strictly follow Scrum practices and deliver fully tested, shippable product at the end of each iteration so the HIP phase becoming somewhat redundant and could just be used for innovations and grooming.
* Release planning issues will be noticeable. In Agile we plan and deliver using small iteration cycles, allowing quick feedback, change of requirements and adaptation. Planning the work for the next 10-15 weeks (even on top level) would be least to say difficult. Mitigation is that the ART should not be seen as a static (in terms of scope) object but instead an Agile – negotiable / inspectable / adaptable body – still the implementation will be difficult in practice.
* Collaboration must be even better than usual. There will be too many dependencies between the different teams and as I imagine, they should start working on the most important feature (from the Epic) in the first iteration of the ART in order to prepare it for release (if needed after the iteration). The collaboration and coherence must be impeccable in order to reduce waste and keep efficient and sustainable delivery.
* Self-management and self-organization would suffer. In Scrum we give freedom to our teams to choose and implement best possible solution in order to promote self-organization and self-management and increase morale, efficiency, quality and the joy of work. With top level System architect, UX, RTE and the other team dependency - a single team will just have to comply and develop what has already been decided/designed in someone else mind.
No comments:
Post a Comment