Since the arrival of Scaled Agile Framework in the world market, there have been comparisons ad nauseum between the Scrum and SAFe® frameworks.
Many industry experts have come out and pointed possible flaws in the Scaled Agile Framework. For instance, Ron Jeffries has expressed reservation over SAFe®’s approach to resolve inter-team dependencies by holding a multi-team meeting comprising of over 250 people (Dependencies & SAFe®).
Ken Schwaber has mentioned that SAFe® does not adhere to the Agile Manifesto values (especially the first tenet – Individual and Interactions over Processes and Tool) as it is highly process-centric (UnSAFe® At Any Speed).
However, the Scaled Agile Framework indeed subscribes to the ethos of the Agile manifesto. Those who have undergone any initiation to SAFe® would confirm that at Team level, SAFe® works very much like standard Scrum, although the teams can also work in Kanban.
At this level, we have an Agile team that is cross-functional and works together to deliver working software every 2 weeks (or 4 weeks as per the discretion of the teams) – which are called Iterations. The content for the Iteration is determined by a Product Owner who is in-charge of the Team backlog.
The Iteration starts with a planning meeting where the team decides what user stories they can deliver by the end of the iteration. Each day the team discusses their progress and at the end of the iteration, they Demo the results to the Product Owner to ensure they have delivered what the Product Owner had wanted. They then get together to retrospect where they can improve for the next iteration before starting the cycle again with a new Planning meeting. All of this is guided by a Scrum Master who makes sure the team works smoothly within the process and that the team also works together to keep improving the process.
In the context of SAFe®, you have multiple Agile teams working independently but in sync. By implication, all teams need to have the same Sprint start date, end date, and duration. This is a key tenet of SAFe® framework and referred to as ‘Develop in Cadence’ in the big picture. Thereby, the basic atom comprising the SAFe® molecule is a Scrum team. The aggregated increment of multiple Scrum teams is the ‘feature’ that has been planned and agreed to be released with the Product Owner (PO) beforehand.
Image credits: Scaled agile
Principles of Agile and Continuous Delivery
Perhaps, the reason behind the success of Scaled Agile Framework is its ability to bring in the concepts propagated by Continuous Delivery and DevOps. As a result, SAFe® has been adopted more rapidly than the older methodologies like DAD (Disciplined Agile Delivery), LeSS (Large Scale Scrum) and Nexus. SAFe® stresses the need to integrate all the Scrum teams’ ‘increments’ at the end of the synchronized Sprints. This ensures that the Software is maintained in a releasable state always. Hence, the motto of ‘Release any time’ is a key tenet of SAFe® framework. In agreement with the key tenets of the Agile manifesto, software is developed in ‘chunks’, maintained in a working state and regular releases to the market bring in the customer feedback needed to improve the software in future increments.
Scaling Challenges in Large Programs and Organizations
With all the good things that Scrum teams have been capable of, there has always been the nagging – scaling challenge. The perennial question – How to scale Agile? The need to scale has been felt in scenarios where a bigger increment is needed or a large program has to be delivered in an Agile manner.
Also, many companies in transitioning from the traditional Waterfall method to an Agile one, seek a proven framework that would help them scale up while adhering to the Lean-Agile principles. Large organizations which have been operating for a long time and may have a variety of processes and micro-cultures across different teams and now want to implement Lean-Agile principles are more likely to look for something “tried and tested” than seek their own approach to scaling. They might use the SAFe® blueprint (or even one of the others such as DAD or LeSS) – not just to Scale Agile but to carry out a deeper organization-wide transformation. In the process, they might well tweak the framework to the way it would work best for them.
Going by the large number of organizations we have come across, Scaled Agile Framework or SAFe® has provided a template for scaling agile principles and tools to large organizations. SAFe® is a framework meant to cover the entire organization. It operates on 4 levels – Portfolio, Value Stream, Program, and Team.
Is SAFe® Agile?
The Agile manifesto at no place mentions the ideal team size for the adherence of its principles. Hence, it would be contentious to state that Agile cannot be scaled. Also – going over the Agile manifesto, the principles do not state ‘how’ to practice Agile. Nor do they recommend any best practices. Agile principles serve as a guiding star pointing to the end goal. They can be taken to scale encompassing bigger numbers of functionaries to collaborate in a creative fashion with the aim of achieving a common goal.
Scrum is a framework that assimilated the Agile manifesto ideas and created a blueprint comprising of Roles, Artifacts, Events and Values that organizations or teams that intend to practice Agile principles of software development can conform to.
The commonalities between Scrum and SAFe® frameworks are that both are inspired by the Agile manifesto. The heart of a successful SAFe® operation is multiple successful Scrum teams developing and integrating into cadence. It is unfair to compare the two and is akin to comparing leaves on a tree to its entire branch. SAFe® brings together the key principles of Scrum, Kanban and Continuous Delivery to offer a framework that does not view all these concepts in isolation but coalesces them with the end goal of working software firmly etched – in alignment with the Agile manifesto.
Perhaps, the most likely reason that SAFe® feels “not Agile” is its overall content, structure, and size. It appears to go against the grain of the Agile Manifesto’s tenet “Individuals and Interactions over Processes and Tools, as Ken Schwaber pointed out! Yet, the fact is that as many enterprises attempt to coordinate and synchronize the output of its various teams to cohesively produce tangible products and services in an orchestrated manner, they have looked for some overall prescription – a framework – with which to be able to do so while.
Is SAFe® Agile? What do you think? Please share your comments/ experience with us!
SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
0 Comments
It seems like the great idea of agility (being agile) has been commercialized into doing agile, which is good, but not better or best, that is, not the ideal. Doing agile will not give as many benefits as being agile. All the talk about being able to creatively come up with a solution with the customer, rather than just pumping out little pieces to get feedback after-the-fact (after release to production).
For a team to have an Agile spirit it does need a place to start from. The framework(s) are probably enablers that seem to give teams (that are new to Agile and haven’t been exposed to that way of working) a reasonable place to start from. It is for the team to eventually weed out the unnecessary and build up on what suits them or even introduce new constructs. As you have stated – it should eventually lead to an imbibing(realization) of the key principle – Customer Collaboration over Contract Negotiation and not just post-de-facto analysis/meeting. How to get there? Journey is the reward 🙂
I think the scrum is a way of implementing single team agile and SAFe is a way of implementing large scale agile (multiple team agile) and hence both have their own significance and yes SAFe is agile for sure. About using scrum in SAFe, it totally depends upon what kind of work we are scaling. Based on the nature of the work, technology, release time lines and other factors we may chose, Scrum or any other frameworks. So there is nothing like pros/cons or comparisons needs between Scrum and SAFe and they are neither complimentary and contradictory. People try to market whatever they are inclined to but the bottom line is both of them are agile and choose what you want based on your needs.
Absolutely, the whole essence of Agile is in the ‘being’ and not in the ‘doing’. The framework(s) by themselves are not the end goal or the answer. They provide the team an opportunity to initiate discussion, reflect and reform. I like how simple practices such as daily stand-up (regular communication) or making work visible (increasing transparency) can have profound impacts on how teams function and think. The ceremonies and the roles play a key part in a team being Agile – both Scrum and SAFe seem to have that. However, a blind practicing of these is not correct and a team must choose and tailor on the basis of their internal workings/dynamics and other factors mentioned in your response.
Here is what I find is not agile about SAFe:
– a truly agile framework should promote “Individuals and Interactions over Processes and Tools” not only at the team level, but at the scaled level too. I don’t see this in SAFe. It seems to promote a lot of processes (PI Planning, Portfolio Kanban,…) over individual interactions.
– dependencies: the goal of an organization should be to realign to eliminate the dependencies rather than manage them. SAFe does not seem to speak much to this – it seems happy to keep the existing corporate structure and hence requires the planning cadence.
– Planning and committing to an Iteration (10-12 weeks) does not seem be in line with responding to change – adjusting based on feedback.
– I did not see much on “customer negotiation”, or even any interaction between the team and the customer (except indirectly as they could be “stakeholders”, or the new “Design Thinking that has been added).
– The roles of Product Manager, RTE, and System Architect subvert the trust for the self-management ability of team members.
– The role of a System Architect goes against “The best architectures, requirements, and designs emerge from self-organizing teams.”
Bottom line: some people may think it keeps teams agile (which I don’t), to me, it does not make the organization agile – it keeps the existing role-based dominance.