There must be some joke about how long it takes an agilest to change a lightbulb — and how it all depends on which framework they use.
We’ve already talked about how you can scale the Scrum framework, by perhaps creating a Scrum of Scrums. But as agile goes from the lean startup all the way up to the Fortune 500 enterprise, how can something so experimental scale? This is what agile coach Ilídio Faria was attempting to do recently when he polled a large agile Slack community for suggestions for the best framework, training and certification to scale agile.
Faria is looking to bring agile to a 600-person team, from one team to more than seven teams, as top-level management wants agile simultaneously implemented with DevOps culture.
“I’m trying to understand if it’s profitable for our company to invest in training and certifications for their consultants,” Faria said.
So today we explore: What is the best agile framework? Or, really, can there be such a thing?
A Rundown of Agile Frameworks
Agile isn’t a fully defined thing — it’s a manifesto of beliefs — and a lot of frameworks and methodologies like Kanban and Scrum can fall under its umbrella and work for teams of all sizes. But there are two officially agile frameworks that come up more often than not. This debate, like many that look to scale agile, centered around those two, so first we outline their similarities and differences.
First, in case you’re new to the subject, let’s do a minute on Scrum itself. Scrum is an incremental, iterative agile software development framework that organizes teams into smaller teams of four to ten people that then break down code and activities into smaller portions, with shorter release cycles, most often two-week sprints. It’s based on the idea that users will constantly change their minds, so your team has to be ready for rapid changes, never planning too far in advance and constantly releasing updates.
It’s interesting to note that the question was about scaling agile within an organization, but only Scrum-centric concepts arose as solutions. There are definitely others solutions, but today we are going to discuss these two big names. We will talk about other frameworks in upcoming pieces.
LeSS: Large-Scale Scrum
“LeSS is Scrum applied to many teams working together on one product.” — Official LeSS Website
LeSS (Large Scale Scrum) is Scrum applied to many teams, but who are working together to ship a specific shared product at the end of a specified sprint.
LeSS contends there is no such thing as a best practice in product development, but rather only practices that are adequate within a certain context. It is a much more fluid framework than others, arguing that calling anything “best” disconnects from motivation and context, slaughtering innovation and continuous improvement.
LeSS includes the following:
- Rules: Like hold an overall retrospective each sprint, these rules are in place to maintain product focus.
- Guides: Tips offered but with the idea they can be continuously improved. (Optional)
- Experiments: A pool of experiments teams can choose from. (Optional)
- Principles: That threads throughout the other three pieces, like focusing on a product as a whole, being customer-centric, and a focus on continuous improvement and transparency.
It’s all about applying the principles of Scrum at a larger scale.
When asked why she preferred LeSS over SAFe, Agile Coach Sarah Baca said, “From the book, it doesn’t create all the layers of bullshit that other frameworks do. It’s essentially many independent teams coordinating together, without a program or portfolio ‘workstream’ that define things and push it down.”
SAFe: Scaled Agile Framework
“Our core belief is simple: Better systems and software make the world a better place.” — Official SAFe Website
SAFe (the Scaled Agile Framework), recently released as version 4.5, covers three main knowledge areas:
- Agile development
- Systems thinking
- Lean product development
And SAFe is based on nine principles:
- Apply the economic context for everything.
- Apply systems thinking, understanding everything links together in a complex way.
- Assume variability, so keep your options open.
- Build incrementally, with constant feedback.
- Frequently evaluate the product alongside the customer.
- Limit work in progress, reduce batch sizes and backlogs.
- Plan across domains toward more certainty.
- Focus on intrinsic motivation.
- Decentralize decision-making.
The general consensus is that SAFe is more of a money-making mission, which means it has had more commercial success. This is clear from their website which offers more of a sales pitch and promise, with more than 70 percent of Fortune 500 businesses having certified SAFe practitioners on-site.
While LeSS is about bespoke work, the SAFe site is all about promising an increase in product delivery speed with four “out-of-the-box” solutions offered. However, SAFe does describe itself as “Scalable and configurable, SAFe allows each organization to adapt it to its own business needs,” for medium-sized teams all the way up to the thousands.
But Which Framework Do the Agile Practitioners Prefer?
SAFe 4 Program Consultant Andrew Leff said, “I have been working in the SAFe framework for a while and it has its pros and cons just like anything. If we remove the money-making certification machine from the conversation, SAFe can create alignment as well as a good foundation if an organization is willing to build learning institutions and not agile prisons. With the revised version of SAFe just released, I like the direction of SAFe 4.5 and the leaner process. I like the feel of the lean canvas they seem to be trying to promote as well as the cleaner picture. It still can feel very heavy as where Spotify [Model] can feel a bit too loose.”
For him, LeSS offers a middle ground that he thinks could be easier to adopt.
“For me, when I coach at the enterprise level, it’s important to understand what the organization is really trying to solve and then experiment on how to best accomplish those goals. Sometimes the decision happens too quick as someone decides to scale without even understanding why.”
Certified LeSS Practitioner Tomas Kejzlar agreed.
“Six hundred people seems like a huge effort. Not exactly how I’d imagine agility — being small, nimble, adaptable and able to ship quickly,” he said. “I think the entire ‘scaling’ business is, well, mostly just business. If you have a few teams, you could do perfectly well without a framework just using what works for you. And even before that, I still believe you need to focus on teams and how do they work individually, especially on their technical practices.
Both Kejzlar and Leff agree that buying into frameworks is a poor investment if you haven’t first decided what agile means for your business.
“Organizations tend to try and fit the framework to existing poor Scrum practice and believe it will help solve issues without understanding [how] it will further amplify them. Understanding how to use a scaling framework to accomplish alignment and provide a better opportunity to help solve real problems and not fix symptoms is often a missed opportunity,” Leff said. “Culture eats strategy for breakfast so getting leadership to lead and not claim victory is part of the scaling challenge, understanding that scaling will become nothing more than a constant list of failure events without the desire to inspect and adapt.”
“Focusing on people and not work to help break down the constraints of command and control is no easy task.” — Andrew Leff, agile coach
There Can Inherently Be No Perfect Agile Framework
As another agile coach Koen van der Pasch put it, “The framework only gives focus and clarity, the professionalism is up to you.”
So if you have a good level of maturity on your team, is that enough?
Original questioner Faria admitted that “We can teach one team to perform with agile mindset without frameworks if they are really good professionals,” though his customers still want to buy into a framework.
Agile advocate Marjan Venema argues there is no best framework, but just companies too insecure to take on the agile process without a standardized framework that other companies have invested in.
“All these questions for ‘best’ are symptoms of insecurities. Allow people to express them openly and get comfortable with not seeking a security blanket but addressing whatever comes up as it comes up — instead of shooting bears before they even appear. [This] will do much more for your agile journey than any framework ever will.” She continued, “After all, being agile is about responding to change because you don’t know enough about the future yet.”
In the end, truly agile teams will beg, borrow, and steal from an array of frameworks and examples from other companies, and then combine all this with the experience and experimentation of their teammates. Code and security best practices can be repeated, but when you involve culture, each team is unique, which makes every large-scale agile situation unique. Of course, this makes it a harder sell to big business who don’t want to take too many risks with the bottom line, wanting to invest in a known solution. Certainly agile at scale takes a lot of time and money, but it also takes a commitment to pivot and change the course of action frequently, in response to team and user needs.
Feature image from the LeSS website.