Be More Agile with LeSS, Part 3: Why LeSS? Why Not Others?
A series on how LeSS can help you solve work problems and boost your team's productivity.
Disclaimer: While the series is a summary of the LeSS book and training, this post 100% comes from my opinion. This exception is needed because if we can’t answer the question “Why LeSS?”, there’ll be at least one loophole in understanding “why we do what we do”.
- Part 1: Why Agile?
- Part 2: What is LeSS?
- Part 3: Why LeSS? Why Not Others? (this post)
- Part 4: Agility Requires ‘Respect for People’
- Part 5 (final): Lean Thinking
As I explained in the previous post, roles & events are only a small part of LeSS. Interestingly, those are enough to tell my opinion on why LeSS is the best fit for DKatalis over other popular scaled agile approaches.
Aside from LeSS, there are 3 other well-known scaled agile frameworks:
Let’s go over each popular competitor in more detail. Then, I’ll wrap up the post by explaining why creating our own scaled agile framework might also not be a good option.
SAFe — Scaled Agile Framework
Here are the roles in SAFe.
As you can see, SAFe maintains a lot of layers (e.g. epic owner > solution management > business owner > product owner). SAFe’s proponents argue that those layers are necessary because the framework is designed for portfolio management (a.k.a manage multiple products). That makes sense in theory, but not in practice. I’ll explain why.
First, we have the role of Business Owners, which have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART). Okay. Now, let’s understand the Product Management role. Here’s the direct quote from SAFe website:
Product Management is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market life cycle.
Do you read the bold texts? Notice the intersection? It’s not over yet. Let me throw you another role that needs to be aligned: Product Owner. Here’s also the direct quote from SAFe website:
The PO has a significant role in maximizing the value produced by the team and ensuring Stories meet the user’s needs and comply with the Definition of Done.
Three roles in SAFe shared the same crucial task! Consequently, they needed to be aligned all the time! That’s after we zoom-in and exclude the solution management & epic owners part. One can only imagine the coordination burden that’ll slow down innovation if we also include those two.
In LeSS, this task will be handled by the one and only PO. If the responsibility for product development becomes too large for one person, it can be shared with Area Product Owners (APOs) that’ll help the PO for each requirement area. It’s even possible for the PO & the APOs to just publish a queue of user problems, and let the teams design the solution. This approach will minimize unnecessary alignment, which is unavoidable in SAFe.
SAFe might be an option for any organization that prefers narrow product definitions, or to put it simply, wants as many products as possible. Also when the CEO really loves a highly bureaucratic and fat organization. Both are not the cases of DKatalis and Jago.
Nexus
Nexus was created in 2015 by Ken Schwaber (Scrum co-creator) and Scrum.org, much later than LeSS and SAFe. In terms of framework, it is more similar to LeSS. So why not go with it?
One of the few differences is Nexus’s Integration Team. Here are some quotes from their 2021 guide book describing the team:
The Nexus Integration Team is accountable for ensuring that a done Integrated Increment (the combined work completed by a Nexus) is produced at least once a Sprint.
The Product Owner, a Scrum Master, and the appropriate members from the Scrum Teams belong to the Nexus Integration Team.
Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership. As long as their Nexus Integration Team responsibility is satisfied, they can work as team members of their respective Scrum Teams.
Common activities the Nexus Integration Team might perform include coaching, consulting, and highlighting awareness of dependencies and cross-team issues.
By its definition, Nexus Integration Team is an elite team.
I personally prefer the way LeSS addresses this issue : let the teams do the job and let the managers (who are not part of any team) increase teams’ capability. Why? Simply because of more team ownership & less elitism between team members. The difference may not appear to be noteworthy at first glance, but I believe it will have a significant psychological impact in the long run.
The other difference is the fact that system thinking is an integral & official part of LeSS. System thinking is a fancy term of ‘thinking in larger context & longer time span’. Yes, system thinking is a necessary habit any academia should have. Nonetheless, if you are a professional working in a large organization (which is already not possible to personally know all of its members), the ability to see & analyze in systems definitely will also boost your career for the following reasons:
- System thinking avoids local suboptimization — a disease of organization. You’ll know your organization is locally optimized when you hear someone say, “As a leader, it’s my duty to fight for my reports’ OKRs. Your OKR is your problem, not mine”.
- System thinking increases our humility. As it teaches that complex systems cannot be controlled, but dynamics can be understood and influenced. Also teaches the awareness of the large consequences a minor habit can have in the future.
- It’ll help you find the root cause of an issue & anticipate future problems/opportunities. In general, you’ll have much better judgements & decisions.
Knowing the two points above (on integration team & system thinking), and the fact that other parts of Nexus are pretty much aligned with LeSS, my personal choice would go to LeSS.
Scrum@Scale
Scrum@Scale, developed by Jeff Sutherland (another Scrum co-creator), is more complex than LeSS and Nexus. However, when compared to SAFe, it has a different level of complexity. The big four consulting firms’ confuse-to-convince selling strategy is immediately apparent in SAFe. Scrum@Scale, on the other hand, is more akin to an idealistic system devised by a hermit-philosopher.
Nonetheless, it proposes a refreshing idea: the Executive Action Team (EAT). It’s a formal team for the executives, which is accountable for removing organization-level impediments, has its own backlog, and acts as the Scrum Master of the whole organization.
I personally like the idea, as based on my experience, executives’ support & engagement heavily influence the company’s agility. DKatalis is lucky to have a representative from agile coaches doing regular checkups with the top-level executives, not to mention Bank Jago itself puts ‘empowered agility’ as one of its company values. So, EAT is less needed in our context.
Aiming to be ‘the operating system of organization’, Scrum@Scale explicitly covers legal, compliance, people operation, and other supporting functions. This ambitious goal separates Scrum@Scale from Nexus, SAFe, & LeSS which focus on product development.
Published in 2019, Scrum@Scale is still fairly new and hasn’t collected many success stories — so not an option for DKatalis. However, considering its uniqueness, I think it’s wise to keep watching the implementations of Scrum@Scale. There might be some inspirations we can adopt.
Our Own Scaled Agile Framework
Why not create our own framework? Shouldn’t it fit our context better? There’s no OJK regulation on this right? :D
A growing organization like ours already has its own problems, and it will only get more complex as we scale. Solely betting on our experiments is doable, but it is also a foolish endeavor in our context. LeSS itself started to form in 2005. Since then until now, many financial firms have implemented it. We need to learn from the successes and failures of others.
DKatalis is fortunate to work with Odd-e (a consulting firm founded by Bas Vodde — one of LeSS co-creators) and has Odd-e senior consultants involved in day-to-day implementation. Having them team up with internal agile coaches increases the overall effectiveness in helping the whole DKatalis & Jago be more agile.
Now that we’ve increased our confidence in LeSS, let’s get back to the LeSS book and training summary. In the next posts, I’ll elaborate on the key principles of LeSS and try to flesh it out with DKatalis implementations.
Do you enjoy working in an agile environment with effective workflow and less friction? Then, you’re already a Katalis at heart! Join us 🤙
