I’ve recently attended Agile events where world-class gurus state that Scrum is broken, the Product Owner is a waste, or LESs is better than SAFe. Tools are built for a purpose. You can use a tool for a certain purpose only in a certain context. When the context evolves, the tools also need to evolve.
What does not change, are the underlying principles. Misuse of a tool is easy if you don’t understand the principles. There are tons of studies regarding ScrumBut, where the Scrum tool is abused. Where the (Agile) principles are not followed, even if the (Scrum) tool is in use.
Maturity of the Organization Defines the Context
According to Reinventing Organizations by Laloux, in today’s predominant organizational model the leader in the hierarchy turns a cog that directs the workers below. Planning and execution are strictly separated. This leads to silos, rigidity, no innovation, no responsibility, no ability to advance meaningfully in the career. Laloux divides cognitive, psychological and moral maturity into five levels*. Higher levels build on top of the lower ones.
|Tribal – “Red”||A simple hierarchy to steer work and a wolf-pack mentality||Mafia and Startups|
|Agrarian – “Traditional”||Large organizations with numerous roles and steering mechanisms, like long and medium-term planning. Planning and execution are strictly separated. Control what and how. Thinking happens at the top, doing at the bottom. The underlying worldview is that workers are mostly lazy, dishonest, and in need of direction.||Church, military and government|
|Industrial – “Orange”||Profit and growth are the most important measurements. Achieved by the means of innovation, accountability and meritocracy. RnD, Marketing and Product Management departments are invented. Control what. The underlying worldview is based on material success.||Multinational companies|
|Information – “Green”||Focus on culture and empowerment to achieve high employee motivation. Highly sensitive to people’s feelings. All the perspectives deserve equal respect. Where Industrial level seeks to make decisions top-down, based on objective facts, expert input and simulations, Information level strives for bottom-up processes. Information level brings opposing points of view to eventual consensus. Where Industrial level views organizations as machines, the dominant metaphor of organizations in Information level is the family. It seeks fairness, equality, harmony, community, cooperation, and consensus.||Culture-driven organizations|
|Adaptive – “Teal”||“Post-postmodern consciousness”. No bosses, no competition. In this mindset, ego is viewed from a distance. We can see ego’s fears, ambitions, and desires: In the Tribal level, a good decision is the one that gets me what I want. In the Traditional level, decisions are determined by social norms of what is right and wrong. In the Industrial level, effectiveness and success are the yardsticks. In Information, matters are judged by the criteria of belonging and harmony. We use measures of inner rightness: Does this decision seem right? Am I being of service to the world?||Network organizations|
Summary of Laloux’s levels of organizational development. The names and colour codes come from Lalouxs’ book, however, they were different in the original work of Beck and Wilber.
Both consciousness and adaptability grows with the maturity of the organization
According toLaloux, in the highest level of maturity (“Adaptive”) we don’t pursue recognition, success or wealth. We pursue a life well lived. Still, the consequence might be recognition, success, wealth, or love. Adaptive organizations reveal three major breakthroughs: evolutionary purpose, wholeness, and self-management. These major breakthroughs make organizations prosper given the right context. Companies like Buurtzorg, Patagonia or Zappos show strengths of the Adaptive level:
- Employees thrive
- Salaries above market rates
- Grow year in, year out
- Achieve remarkable profit margins
Adaptive level brings three organizational breakthroughs:
- Principles driven decision making. Rather than trying to predict and control, Adaptive organizations try to sense and respond. Similarly, as the Cynefin framework describes working process in the complex environment, that consist of “unknown” factors. The output cannot be planned predicted, but one must proceed with principles driven decision making in an environment where it is safe to fail. Like Stephen Covey says “There are three constants in life: Change, choice and principles”.
- Wholeness creates an environment of safe conversations. Safe conversations invite deep listening, authenticity and vulnerability. It is assumed that everyone seeks for the common benefit, even if their opinions seem different. Conflicts are dealt with understanding. This will create smarter networks, unleash creativity and bring higher employee satisfaction. Like Douglas Stone says “The urge to blame is based.. on the fear of being blamed.”
- Minimum Viable Management does not mean a free-for-all. It means form-follows-need: Roles are picked up, discarded, and exchanged fluidly. Power is distributed. Decisions are made at the point of origin. Innovations can spring up from all quarters. Meetings are held when they are needed. Temporary task forces are created spontaneously and quickly disbanded again. The leaders of self-managing organizations feel, that it is less risky to deploy self-managed teams. That self-managed teams make better decisions. Like Bruce Lee stated “It’s not the daily increase but daily decrease. Hack away at the unessential.”
These three principles enable the organization to better handle uncertainty, complexity and magnitude of nowadays Agile business. Adaptive organisation work efficiently and fast, while fewer power games and egoism is in the way of creativity. More effort is used on improving individuals and organizations.
Where to Start
Team of Teams by McChrystal underlines the idea of creating nimble, transparent, and horizontal organizations. Organizations which empower their people to execute based on the concept of ‘shared consciousness’. People are empowered to trust their gut and use their best judgement based on their training and knowledge of organizational goals. The book gives good ideas of
- Break down organizational silos by sending liaisons to other teams
- Empower everyone to make decisions, don’t act as a decision bottleneck
- Hold frequent sync up meetings to disseminate information
- Set up cross-disciplinary open-plan workspaces
- Enable people to make decisions at lower in the hierarchy and get to know their counterparts in other teams
- Be a gardener. Plant and provide water and nutrients. No heroic micromanagement
- Monitor data and real-time information, but stay away from control-freak and micromanagement.
From hierarchy to networks (Team of Teams way of drawing the idea)
Need for Speed
- Formal: the official organizational chart and the job descriptions
- Extant: how things actually work and who really makes decisions
- Requisite: a setup that would be most natural and best suited to the work and purpose of the organization.
The Idea of The Holacracy is to achieve the requisite organizational structure. Holacracy’s systems and processes are about helping the organization find its own unique identity and structure. In Holacracy, a pyramidal hierarchy is replaced with “circles” dedicated to specific functions. Each of the circles has a “lead” who, like a traditional manager, is responsible for assigning work and seeing that it’s completed. They, however, are not responsible for determining how the work is done. A kind of company-level crowd-sourcing.
From hierarchy to networks (Holacracy way of drawing the idea)
Fit For Purpose
There are no good or bad ways to organize. The question remains whether the structure is a good fit for the task at hand. Mature levels are better suited for the purpose of more sophisticated work, with high complexity and high skill set. And lower levels are better suited for crisis situations. The organizations are far from consistent and are a mix of both. The maturity of an organization is influenced by the context and by the leader of the organization.
Back to Scrum
Scrum is not an absolute value. Just a tool. Originally Scrum was a counterattack to Waterfall. From fixed scope to work decomposition, fast feedback, retrospectives and being close to the customer. The idea of Agile is to create high value to the customer by means of collaboration, demos, improvement and being open to change.
In this context Scrum is a process to take an organization to the next level of maturity. Scrum gives the management a feeling of top-down control by managing the product backlog. Simultaneously Scrum provides the team with a freedom and safety to make bottom-up decisions. At some point, there is no more need for the safety provided by the hierarchical Scrum mechanism. Similarly, you may evolve from component teams to feature teams.
What makes the tools like Scrum, Kanban or SAFe work are the underlying principles like
- Agile (https://gofore.com/agile-transformation-action-part-1/ )
- Lean (https://en.wikipedia.org/wiki/Toyota_Production_System )
- Systems Thinking (https://gofore.com/en/what-is-systems-thinking-and-how-should-i-use-it/)
- Cynefin (https://en.wikipedia.org/wiki/Cynefin_framework)
Agile is about adapting to an unclear situation by using regular feedback loops and prioritization. Lean is about regular retrospectives and improving the ways of working. Systems Thinking and Cynefin teach about system dynamics and how to operate them.
Keep the principles in mind and use them as your guiding force. Build on strengths and potential. Understand the context where you operate. Each context presents different dynamics. Keep in mind the ‘fit-for-purpose’ of each tool. Any tool can be abused if it is used following the wrong principles. Consequences are governed by principles, not by the tools. Therefore, value principles.
* The evolutionary model presented comes originally from Don Beck, whose work was borrowed by Ken Wilber.
Welcome to the sequel of SAFe versus LeSS adventure! The first SAFe vs LeSS blog gained attention and we were able to pick more emphasized questions.
Q1: Any over-arching framework is wrong a priori, isn’t it?
Jari: Some may state that you can’t define a framework suitable for any Enterprise. This can be seen a priori being a false assumption, while no rigid process fits to all the enterprises. One may continue by saying that you can’t have a combination of “Agile” and “Framework”. Agile means freedom of choice, while Framework is a process. Framework stifles the change needed in the organization. Agile Manifesto states “Individuals and interactions over processes and tools”. So one may say that any predefined process is anti-Agile.
Q2: How to deal with the “Weaponized Agile”?
Jari: “Weaponized something” is where the management uses agile sounding words to get ahead of the change and stop it.
- The program management structure of SAFe might create a construction for abuse. A multi-level management structure provides a fruitful platform for narcissist powerplay associated often with heavy hierarchies.
- LeSS provides less possibilities for hierarchical powerplay. LeSS HUGE has roles of PO and Area POs. However, LeSS provides plenty of freedom. Freedom for each PO to selfishly develop what matters most for themselves.
In my opinion frameworks don’t hurt people. People hurt people. Corrupted people find their ways of working in any form of organization. Do not operate with bad people.
Q3: LeSS is difficult to sell toward higher management (who will get sacked).
Juhana: It’s true that the LeSS approach is more radical than the SAFe approach. While SAFe focuses on monetising the agile transformation process, LeSS reveals the real agile principles and values. There are a few patterns that help to reduce managers’ resistance towards LeSS:
- Highlight the ‘job safety, but not role safety’ rule of LeSS. Even in LeSS managers are critical for to the system to operate. The management turns themselves into system thinkers, learners, and teachers.
- Focus on teaching the principles. Show how the LeSS principles effect organisation policies, procedures, and structures. Show how the LeSS approach solves existing problems. Keep the Scrum and LeSS jargon to a minimum until the agile adaptation is thoroughly implemented. Point out the learning opportunities. Many former developers are excited by the opportunity to return to hands-on development.
- Is a surgeon more recognised than a hospital manager? The same mind-set should be applied in product development organisations. Hold unofficial mini training sessions for managers. Be open and explain the principles and values behind LeSS. Remember to include managers in the new organisation structure.
Q4: SAFe is program centric and doesn’t force the change. Adopting SAFe is a way of avoiding coming to terms with the inherent problems in the organization, isn’t it?
Stefan: SAFe has a clear implementation roadmap. The implementation roadmap starts with training the change agents and then addresses the executives and managers. Leaders will be involved in the change. Their role will be to provide sponsorship or to directly contribute to the implementation of SAFe. The adoption of SAFe requires that leaders embrace lean-agile mindset. SAFe will expose the impediments of the organisation sooner or later – also the impediments at management layers.
Q5: LeSS is more about Principles and less about Tutorials. This means that you need a highly skilled practitioner to be able to apply it into practice, doesn’t it?
Juhana: A change management requires the implementation, and the agile transformation is not an exception. You need an agile coach who has a strong knowledge of agile approach, coaching, and product development. The coach mentors and teaches core personnel of the organisation. Anyhow, motivated people learn agile rapidly. It is not rocket science. LeSS is anyhow easier to adopt compared to process-oriented SAFe, which even has its own glossary. The external agile coach role is also temporary. Scrum Masters and ex-managers will take charge fast.
Q6: SAFe is easy to sell. Executives like everything that comes in a box. SAFe comes in the box and hence is attractive. The reason SAFe is easier to sell, is that it doesn’t really require people to become Agile. Or does it?
Stefan: SAFe is a collection of battle-tested practices and operational models. It’s true that it’s attractive and easy to sell. But it also requires changes in how organisation works. The team level results will be visible after the first sprint. On program level the results are obvious after an increment. Thus, it should be fairly straightforward to judge based on the results. SAFe requires agility not just from developers and teams, but from the whole organization.
Q7: What is the business case for agile transformation? What is the cost structure? When would ROI reaches the tipping point?
Juhana: Shipping speaks louder than words. LeSS brings benefits of dramatically dropped cycle time, simpler organisation structure, and higher job satisfaction. SAFe might give you the same result, but much more slowly and painfully. What is the cost when the organisation won’t adapt faster feedback loops or benefits of the cross-functional teams? Go and ask from the competitors of Tinder, Airbnb and Amazon. Organisations don’t fail when they take risks. Organisations fail when they stop taking risks. LeSS takes effect from the first day. The adaption process is straightforward, as you can see from the previous post. The agile transformation is an investment which has a short payback time!
Stefan: Companies must find ways to tackle and conquer the ever accelerating market and technology changes. The goal of agile transformation is to accelerate the organization. To enable the organization to deliver more value in less time. With happier employees, increased productivity and improved quality. LeSS might seem like an easier and simpler solution, but actually it requires much more from the organisation that will adopt it when compared to SAFe. SAFe allows you to configure and scale it according to your needs. SAFe also provides proven implementation instructions, which help you to get started faster.
Jari: Both systems have been developed while using them in the real life business. The systems evolve all the time when more is learned about scaling Agile. According numerous case studies the impact of Agile transformation is visible from the day one and ROI is considerable. You can read the real life war stories from https://less.works/case-studies/index.html and http://www.scaledagileframework.com/case-studies/
Q8: Finally, as a summary. We can now clearly see that LeSS and SAFe aims to different markets and different kind of organizations. Where do you see that your frameworks would suit the best?
Juhana: LeSS is a product development framework for creating products with a high degree of variability. LeSS fits every organisation, whose core values are transparency, continuous improvement, and customer centricity. And unlike SAFe, LeSS follows these values!
Stefan: SAFe addresses the needs of small, medium and large companies. It does that by allowing organisation to select and configure the parts needed. SAFe allows jump start even for big companies, and you can start from top, botton and middle at the same time. With LeSS you would need to start from the botton and work you way up, which will take time.
While the comparison often tend to narrow down the vision, I would like to end the blog with a quote from the book Leadership and Self-Deception By The Arbinger Institute:
“Success (as a leader) depends on being free of self-betrayal and creating an environment of openness, trust and teamwork, where people work hard for the collective good, not individual accomplishments”
Thanks for reading!
First of all. Ahoy, all you “Why agile” and “I don’t need scaling, I already have Scrum” people. Please start here.
I’ve followed the growing interest towards methods of scaling agile for the last decade. Personally I faced the idea of scaling Agile, whilst working as a subcontractor for Nokia. Back then two very different kind of frameworks were born. Ari and Ran explains the history of these scaling frameworks, so I won’t go there. I’ll just want to find out, which approach is better. The fastest and most entertaining way is to take our two of the most experienced scaling agile gun men Stefan and Juhana and start shooting. Whilst the gun men are warming up, let’s make a quick generic comparison of the frameworks.
We’ve blogged earlier about SAFe (in Finnish) and LeSS in rather positive tone – now it’s time to get some friction between them. Like in all the unforgettable shootouts, the tension must be built gradually from introduction and rising action towards climax.
I must say, if I created a scaling framework, I wouldn’t name it either “Safe” or “Less”. The “Less HUGE” makes things even more paradoxal.
There is a clear winner on the field of naming the Scaling Agile framework. The Recipes for Agile Governance in the Enterprise aka “RAGE” wins the fight between names.
Never, ever design usability restricting cr*p on any media in the name of copyrights. It is a lose-lose deal.
- The hippie drawing style of LeSS will make all the wave riding, new age developers feel warm and fuzzy.
- The engineering style, mind-blowing-in-details drawings of SAFe will make all the managers feel super important. However, the copy-paste restriction of SAFe portal sucks, while it also disables for example text search of browser.
LeSS wins the fight between the portals.
We live in a colorful world. Use them.
- Both books are the same diameter and around 330 pages.
- Both books come from Addison-Wesley.
- SAFe book has more pictures and colors, otherwise they are rather similar.
SAFe wins the fight between books with flying colors.
Introduction of The Gun Men
Question #1: Tell us a little bit about yourself and when you became a fan of SaFE / LeSS?
I’m a business manager and consultant at Gofore. Currently I’m focusing on our customers in health technology, healthcare, social care and wellbeing businesses. Throughout my professional career I’ve been interested in all development methods – from SW development to business & customer development. I was first exposed to SAFe whilst working at Nokia a decade ago, but the real revelation of SAFe to me happened at GE Healthcare in 2014. We had 16 teams, nearly 200 professionals scattered across globe with a goal to create multiple new products together. We applied SAFe to align the goals, sync on delivery and to optimize flows.
I’m a lead consultant of software development at Gofore. I have a background in software engineering and have been in the IT field for more than decade. I’ve taken part for some of the biggest public sector digitalization endeavours in Finland. For some reason, I’ve always been the guy who’s removing obstacles and trying to improve everything. So, the Scrum Master’s duty was a natural choice for me. Lately, I’ve focussed on transforming entire organisations to Agile mode. In the latest project, I was consulting a large software program that required Agile transformation. I needed a powerful and straightforward solution for the transformation. The LeSS approach caught my attention very quickly; the LeSS principles and rules were understandable and simple. The challenges confronted in the target organization were tackled intelligently with the LeSS method. This would not have been possible if using a one-size-fits-all format such as the SaFE.
SAFe interest people in management type of roles and LeSS fascinates adventurous problem solvers.
Question #2: Imagine a 40 person project working in waterfall model. How would you deploy SAFe/LeSS?
Educate everyone into Agile mindset
SAFe provides the best practices from industry also for the deployment of SAFe. The things to conside in deployment are:
- Train everyone: a) train the leaders, b) train the internal change agents, and c) train project personnel.
- Split project to 2-pizzas-serves-them teams. Select team level development methodology, e.g. Scrum. Make sure that teams have the right set of competences to work as feature teams.
- Define the way of working for the organization. For a 40 person program the two lowest level of SAFe framework serve the purpose: 1) Team level and 2) Program level.
- Then it’s about start your Agile Release Train to develop in common cadence according to commonly agreed increment plan. The increment planning and demo sessions are where the magic happens – the whole program planning, resolving and agreeing together in the same room and at the same time.
The LeSS creator Craig Larman’s advice for large, multi-site, and/or offshore programs is just ‘don’t do that’. Instead pick the ten best developers. If you must scale, here are the adaption principles:
- You should educate everybody. The easiest way is to sign people to the Scrum and LeSS trainings. The formal coaching is followed up by a team, organisational and technical coaching.
- Define the product as broadly as possible. A broader definition tends to be more customer centric and creates simpler organisations.
- Define the ‘DoD (Definition of Done)’. A better and stronger DoD eliminates groups, roles, and positions.
- Have appropriately-structured teams. One team member belongs to only one team, and the teams are stable, long-lived, cross-functional, and co-located. Only the Product Owner provides work for the teams. Keep managers away from the teams.
Both approaches aim to educate and engage everyone.
Question #3: Our current organisation has 3 team leaders, 1 architect, 1 project manager, 1 product manager and 1 UX/AD specialist. What would these persons do in SAFe/LeSS?
When using Scrum on team level then there are roles of the Scrum Master, Product Owner and SW developers. On program level you’ll find Product Management and Business Owners. Note, that the role of leaders in SAFe is different from traditional management – the roles are Lean-Agile leadership type of roles.
- The old team leaders from the legacy organization could become developers, Scrum Masters or Product Owners depending on their capabilities and desires.
- Architect and UX/AD specialist could continue working across the teams in program level roles.
- Project manager could be promoted to the role of Release Train Engineer.
- Product Manager could continue with same title, but in a modified role at product management.
Specialised roles are forbidden in LeSS.
- The team leaders can become Scrum Masters. They should follow the servant-leadership-mindset such as putting people first, coaching, removing obstacles, and creating the community. One Scrum Master can serve one to three teams.
- The Architect and UX Designer will each join a team. In addition, the architect can lead or be part of the architect community, and the UX Designer can lead or be part of the user experience community. The communities ensure the cross-cutting quality and are run by the team members.
- the product Manager can take the Product Owner’s role and responsibilities.
- The project Manager could focus on increasing the capability of the organisation’s value delivery with using techniques such as ‘Go and See’ and ‘See the Whole’. The Product Manager role is also temporarily needed if there is a weak Definition of Done.
Tune-down way of SAFe makes it easy to sell towards legacy management. SAFe has built-in program management process and roles. Build-up way of LeSS asks “How to simplify the organization, and be agile?”.
Question #4: Okay, now the program is working according to SAFe/LeSS framework. How does the model scale when you add two more teams?
SAFe’s program level guidelines make this rather easy. Assuming the teams are feature teams then it’s rather easy to add new teams – just invite them to the common Release Train Planning event and share the prioritized increment backlog across the teams. SAFe can scale up to multiple release trains and multiple value streams, but at that extreme we would be then talking about thousands of developers, and that’s a bit scary anyway.
LeSS scales easily – you just add two more teams to the structure. Avoid creating component-based teams such as front-end, integration, or operation teams. If the number of teams exceeds eight, use the LeSS Huge framework. It’s based on the same principles and rules, but adds a few extra practices.
After reaching Lean Agile organization scaling is easy.
Both models require the Enterprise to change. Agile is about mind-set, not about roles or processes.
It seems that the path for agile scaling is rather similar, no matter what framework you are using. After the first hour of shooting, there is yet no clear winner.
Thanks for reading! Please, throw in any additional questions!
We will tackle those in the Shootout Sequel, where we will finally find out, which one of these two frameworks is the best.