After almost 10 years, I got chance again to work on a LeSS Huge adoption. Facing different challenges and reflecting on my experience 10 years ago, I am proposing an experiment here to decouple line organization from requirement area.
NSN experience
In 2007, I experienced an organizational transformation in NSN (Nokia Siemens Networks) to adopt LeSS, at which time the name “LeSS” had not yet existed. We had transformed the organization into a LeSS Huge setting with a few requirement areas, in each area there was APO (Area Product Owner) and Area manager. Area manager was the line manager for the area. We used the same name for requirement area and line organization, for example, the area I worked for was Traffic & Transport, both as requirement area and line organization. So, requirement area and line organization are coupled.
Even though the workload in one requirement area is more stable than one feature, if we follow priority based on customer value, it is inevitable that the workload varies as time goes. So, today you need 5 teams working on this requirement area, tomorrow you need 6 teams. I am exaggerating, this would not be “today/this sprint” vs. “tomorrow/next sprint”, but more like “this quarter/this year” vs. “next quarter/next year”. Anyway, this happens. When it happens, LeSS recommends to move team, rather than individuals, to other requirement area. When requirement area and line organization are coupled, it means that the team would also change the line organization. As you can image, line change is never easy. Everybody may agree that this makes sense and support, the necessary justification and convincing others carries big overhead. Even today when I reflected back, I could still feel the very pain. Yes, the silo among requirement areas was clearly there and the coupling with line organization made it worse. Interestingly, the developed silo was also one of the reasons why we chose to couple line organization with requirement area, because that way, line organization would have more product ownership, not for the whole product, but for the requirement area.
Although it was painful experience to move teams to different requirement area, it did not happen often, as the workload seemed stable in requirement area. In retrospect, i suspect that the prioritization decision may consciously or unconsciously take the capacity of requirement areas into account.
New challenge
Recently, I encounter a different challenge. In the context of my LeSS coaching client, their workload between two requirement areas varies release by release. Say, there are 5 teams in each requirement area. In release 1, based on priority, 60% of work is from requirement area A, and 40% of work is from requirement area B. That translates into 6 teams for requirement area A and 4 teams for requirement area B. However in release 2, only 40% of work is from requirement area A, while 60% of work is from requirement area B. If we have requirement area and line organization coupled, we basically have two options. First, we do not follow the priority strictly and take the work considering the capacity in each requirement area. Second, we move teams to different requirement areas release by release, as line organization is coupled, we change their line organization as well. As their release cycle is 3-4 months, it would be hectic to make so frequent line change.
New experiment
In fact, we have the third opinion, which is to decouple line organization from requirement area. Once it is decoupled, we may move teams across requirement areas but not change their line organization. Let’s illustrate this with the below diagram (RA = Requirement Area).
2 line organizations (A and B), each having 5 teams
2 requirement areas (RA1 and RA2), with varying number of teams
Release 1, 4 teams for RA1 and 6 teams for RA2
Release 2, 6 teams for RA1 and 4 teams for RA2
The name for requirement areas is often associated with product domains (customer domains, rather than architecture domains). Hotel, Flight, etc. would be suitable names for requirement areas in Ctrip type of product, assuming that each is big enough to justify as its own area. However, we name line organization without referring to product domains. It could simply be product line group A, B and etc.
In LeSS Huge, one rule says that each team specializes in one RA. In this case, we can’t let A5 and B5 specialize in RA1 and RA2, respectively. Instead, we would like them to be able to work for both RA1 and RA2. Would that cause problem? Let’s first understand the rationale behind the rule. It is usually difficult for any team not to specialize in any area, as the whole product in LeSS Huge is too complex for any team. This holds true by and large. However, there are a couple of subtle differences here.
We are talking about minority of teams, for most teams (A1-4 and B1-4), they still specialize in one requirement area. It is likely to enable small number of teams who can specialize in more than one requirement area.
Team A5 and B5 may not specialize in RA1 and RA2 completely, but to some extent, e.g. some sub-areas in both RA1 and RA2. The key is to have the flexibility in addressing the workload variation in requirement areas across different releases.
Another potential downside for the decoupling is that line organization would not develop strong product ownership. While this is true for requirement area, too strong ownership for one requirement area may lead to silos within one product. Thus, the decoupling also has the potential in reducing silos if we can make any line organization care more about the whole product.
Conclusion
Regardless of what choice you make - either coupling or decoupling, I suggest you to understand deeply those forces in the dynamic, thus, make informed choice.
Recently, I was chatting with my friend (and a LeSS site developer) Terry Yin and we were reflecting on two different product development efforts.
He had been working with a client and the Sprint Review was boring as hell. People didn’t really care. Also the teams didn’t care whether they had done items during the Sprint anyways. When debugging this a bit more, it seems to relate to fixed-scope assumptions. Even though they said they had adopted LeSS, they still had this mindset of a fixed scope for a release. So, the Sprint Review led to no learning and no action, and the Sprints felt artificial.
On another effort where we were working together (smaller), we noticed that it was common to have the Sprint have all new items that weren’t in the Product Backlog in the previous Sprint. Most of the items were discovered during the Sprint Review. The backlog and scope was changing constantly. We kept a Release Burndown chart and it was going up, down, up, down, up and then when we decided to release, down in a straight vertical line.
The difference… true agile exploration vs agile movements in a traditional setting.
So, half jokingly, we came up with “Terry’s Agility Index” which we defined as:
The percentage of new items during the Sprint that came out of the Sprint Review.
Since then, I’ve mentioned it a couple of times and it often surprised people. Lots of so called “agile” projects would have a Terry’s Agility Index of 0%. Now, 100% is probably not good either, but it is an interesting quick way of checking how fixed the fixed-scope mindset is in a product group.
“In this age of agile development, there’s an uncomfortable reality that needs to be acknowledged and that is that large scale development is still with us. That’s a problem that needs to be faced up to,” argues agile coach, Venkatesh Krishnamurthy.
“Modern product development is done through short cycles incrementally building up the product. Small teams are considered better. That said, a lot of people live in a world of large product development. I’ve not come across a smooth-sailing, large scale project or product development,” he states. “They are all plagued with funding, coordination, structural and cultural issues. With so many moving parts, it is difficult to come up with a single formula that could make large-scale program work.”
At the lower end of the spectrum, smaller teams are able to turn to Scrum. For smaller teams, Scrum based on empirical process control has not only proven itself but has become the most popular framework. But for larger scale programs, something more is needed. That more is LeSS.
LeSS is Large-Scale Scrum, a framework created by Bas Vodde and Craig Larman based on their work in the telecom and finance industries. They worked around the basic idea of needing something that is based on Scrum but which could scale to meet the needs of larger product groups.
Where it differs from Scrum is it adds a more concrete structure with the aim of maintaining transparency while emphasizing the “inspect-adapt” cycle to allow groups to improve continuously their own ways of working. “From the learning perspective, LeSS provides a clear and concise framework,” explains Krishnamurthy. “LeSS is about taking Scrum and asking how we can apply the same concepts across multiple teams?”
LeSS consists of:
LeSS Principles
LeSS Rules (defining the LeSS Framework)
LeSS Guides
LeSS Experiments.
It also comes in two flavours: LeSS and LeSS huge. The former can be applied to up to eight teams, while the latter is appropriate for more than 8 eight teams, even couple of thousand people working on a product.
“LeSS also brings good ideas and principles from systems and Lean thinking,” says Krishnamurthy. There are several large scale frameworks out there trying to provide solutions only from a delivery perspective. They won’t address the root causes of the problems.
“LeSS does not promise a quick fix solution, but rather it provides the rules and frameworks to build a strong foundation for the organizations to succeed with large scale development.”
And at the centre of LeSS and its evolution is Scrum. “Large-Scale Scrum is Scrum; it is not ‘new and improved Scrum,’” insists Krishnamurthy. “Rather, LeSS requires examining the purpose of single-team Scrum elements and figuring out how to reach the same purpose while staying within the constraints of the standard ‘Scrum rules.’
“Many practices from Scrum relevant for single teams are applicable in LeSS with multiple teams,” he adds. “For example, single product owner, single product backlog, one potentially shippable product increment at the end of each Sprint, cross-functional teams with the ability to deliver end to end work, stable teams and so on.
“There are minor differences in the way Scrum ceremonies are conducted in the context of LeSS and this is mostly to make it work in the multiple teams scenario. For example, Daily Scrum is done independently with each team, ceremonies like Sprint planning, review don’t need all the team members but key representatives with Product owner.”
There are organizational implications that need to be factored in, advises Krishnamurthy. “The structure of the teams, groups and roles they play are critical in driving the team’s behavior. That is why, LeSS has a special place for structures. LeSS recommends organizations focus on structures first before rolling out LeSS.
“Some of the LeSS recommended ideas around structure include organizing the team by customer value as well as creating feature teams rather than component teams. A number of deep Lean ideas around management are also evident in LeSS, such as the concept of managers as teachers who create a culture of improvements for teams.”
Krishnamurthy is quick to point out that LeSS has not been conjured out of thin air as a response to a problem. Rather, it has evolved across decades of experimentation in different contexts. “I have personally been involved during the initial days of LeSS experimentation, working in a services industry with geographically distributed teams in USA, Germany, France and India,” he says.
There are several case studies worth looking at from different parts of the world, he adds, including J.P. Morgan’s (JPM) Global Core Processing Technology’s 3000 plus strong development organization which adopted LeSS in 2013., agricultural machinery firm [John Deere] (http://less.works/casestudies/john-deere.html) and Telecom Australia.
There are two very different strategies in adopting Agile in a large organisation, horizontal or vertical. In other words, you may take one product first with narrow and deep focus. Or you may focus on the vertical coordination layer, which is often perceived as The Scaling Problem.
First we look into the fascinating world of control, power and culture at different layers of a large organisation. Based on this analysis we draw our conclusions about the transformative power of LeSS and SAFe.
Ouchi also studied mechanisms of controlling work in large organisations. He focused on two simple questions:
What are the mechanisms through which an organisation can be managed so that it moves towards its objectives?
How can the design of these mechanisms be improved, and what are the limits of each basic design?
He identified three different mechanisms by which the control was achieved: Market, Clan, and Bureaucracy.
In real life these co-exist, but typically one dominates.
Different ways to control the work evolve based on two factors: First, are we able to measure the output, and second how well we can describe the transformation process of the work, from input to output. The following matrix classifies the conditions for the different types of control:
Layers of control and power
Let’s look at a typical large product development organisation. It may be for example the internal product development of a bank, or a commercial telecom infrastructure provider. The top management is in contact with the owners and market realities. At the bottom there are the front-line workers, in direct contact with the technical realities. The middle layer is mostly dealing with internal questions of control, coordination, intermediation, analysis and execution.
Top management – Market control and Reward power
Top management is in direct contact with the capital market and business market. They have real profit and loss responsibility for the whole company or a business unit. They make decisions on behalf of the whole: where to invest money, if a product is started or cancelled, or people hired or laid off. They have power over resources, which is called reward power.
Market control is the dominant mechanism here. It is about money. You can look it as investment game; where to get the biggest return for my money. I don’t need to know how things happen inside the organisation, but the input (money) and output (what it I get with my investment) are measured.
Market control is not feasible when an exact contract can not be made or the parties involved can not measure profit and loss. Market control also requires competition that creates an incentive for both parties to do their best, and makes sure work is done using on fair price.
Front-line workers – Clan control and Expert power
Front-line workers create the product. They work with technical realities. They have expert power – decide how to solve technical problems. Clan control is the only control mechanism that functions well when the work performed is unique, interdependent or ambiguous like software development.
Clan control is based on informal shared values and rules, traditions and beliefs. It works when the goals of the individuals and the organisation are aligned, and there is a high level of trust. Building Clan control is hard since the controlling rules are mainly informal and value based. It requires thoughtful hiring. Also, people need a long period of socialisation in order to become members of the clan.
Clan control may work at any levels of the company, but is mostly observed amongst front-line workers and teams. When the problems require, Clan control enables the most economical collaboration between front-line workers. There is no hierarchy or predefined bureaucracy that needs to be taken into account.
When observed from outside, Clan control seems to have no control. New managers often try to control the front-line workers by establishing more bureaucracy or market control. It makes Clan control hard to achieve, because other control mechanisms easily dominate.
E.g. The top management hires professional coordinators (project/program management) and gives them hierarchical authority to manage and evaluate front-line workers i.e. installs Bureaucratic control. Or the top management establishes Market control by adding evaluation and reward practices where the front-line workers compete against each other to get the rewards. These control mechanism instantiated by top management fail to work, because software development is inherently complex, unique, ambiguous and interdependent. Front-line workers in software development painfully experience and recognise this mismatch. It causes constant conflicts and frustrations between front-line workers and middle management.
The middle management – Bureaucratic control and Dependent power
The middle management works with the internal realities, possibly many handovers away from any external realities. They transmit the business contract to the front-line workers. They coordinate between different teams or individuals. They do all kind of analysis, plans and work supervision for the whole system. The legendary researcher Nonaka, the grandfather of Scrum, said that good project managers, who translate between the business and workers are essential for the successful Japanese companies (a few decades ago).
The top management has delegated some power to the middle management. The front-line workers have given some power over their doings to the middle management. So the power of the middle management depends on top and bottom. When there are many middle managers, they are also dependent on each other. They need to negotiate, which is called politics. The more middle managers, the more different roles, the more difficult politics. The level of complexity in this mess is reduced by agreed rules, responsibilities, processes and authorisations – bureaucracy.
The Bureaucratic control identified by Ouchi is based on rules, policies, a hierarchy of authority, written documentation, standardisation, etc. To make a bureaucratic organisation work managers need authority to maintain control over the organisation. One example of this control is the employment contract, where employees give power to managers to direct and evaluate their work. Employees trust that management will do a fair job in evaluation.
The German sociologist Max Weber argued that bureaucracy constitutes the most efficient and rational way in which one can organise human activity. Systematic processes and organised hierarchies were necessary to maintain order, maximise efficiency, and eliminate favouritism and other misuse of power. But Weber also saw unfettered bureaucracy as a threat to individual freedom, in which an increase in the bureaucratisation of human life can trap individuals in an “iron cage” of rule-based, rational control. – Wikipedia/Bureaucracy.
“What is not often understood is that bureaucracy developed as a reaction against the personal subjugation and cruelty, as well as the capricious and subjective judgments, of earlier administrative systems (such as monarchies and dictatorships) in which the lives and fortunes of all were completely dependent on the whims of a despot whose only law was his own wish.” – Evolution of Management Thought, 6th edition.
Bureaucratic control breaks when the work process is ambiguous, invisible, unpredictable. It also breaks when managers can not fairly evaluate the employees. Both of these happen easily in software development. The management often responds to these failures with more bureaucracy, which is part of the scaling problem.
Bureaucracy dominates
The control mechanism type evolves from the system conditions, based on what is possible, and what is economical. Ouchi compares the control mechanisms with fish living in different kind of environments. Market control is a salmon, and Clan control a trout. They survive only in clear oxygen-rich water. Bureaucracy is like a catfish. It survives everywhere, also in muddy waters. It is the winner, as long as the organisation stays alive.
The fundamental mechanism of power, as recognised by Ralph Stacey, is “Power constrains the enabling conversation in organisations.” You enable desired patterns by releasing constraints and dampen undesired by adding constraints. You direct by lowering constraints in the desired direction. From this follows that it requires skill to use power with minimal friction and loss of energy. Bureaucracy is very effective in creating constraints. The more fragmented organisation, the more (conflicting) rules, the more friction – waste.
Control in Scrum
One-team Scrum beautifully creates the minimal bureaucracy, that enables the Market control and Clan control to be in dialogue. There are some rules but no middle manager roles.
The product owner can make a bounded risk investment. The input is measured accurately. Referring to Ouchi’s definition of Market control, the Product Owner can evaluate the result after an iteration. The Product Owner herself is evaluated based on her achievements using Market control. The team has conditions, which enable Clan control, for example a clear goal, immediate feedback, autonomy over it’s own ways of working, and empowerment to act on emerging impediments.
How to scale this to large organisations?
Organisational layers in LeSS and SAFe
We have now analysed the layers of a typical large organisation and compared it with the elegance of Scrum. Next we look how LeSS and SAFe deal with the layers in large organisations.
More with LeSS – minimise bureaucratic control
LeSS has Scrum in the center. It provides a set of principles, rules, guides and 600 experiments that help to change the surrounding organisation so, that Scrum scales up to a whole organisation. From the control perspective, this means minimising Bureaucratic control and getting Market control and Clan control into a close dialog.
LeSS adoption aims to remove the coordinating and intermediating middle management roles. The teams need to have as direct contact as possible with the business and with the customers. There is no program (coordination layer) – the empowered real Product Owner decides, and Teams with direct customer interaction clarifies needs. This reduces the work for the bureaucratic layer dramatically. What to do with the coordinators and managers? They will learn new things, move into teams, move to product management to work with the customer, or take a coaching role. There is job security, but no role security.
Reducing Bureaucratic control is only possible when the whole organisation from the real business to teams is changing together. LeSS has narrow and deep focus to ensure enough support for the organisation changing, to limit the risk, and to have a real working example for the neighbouring products after the first success.
Play SAFe – better coordination
The SAFe big picture fits perfectly to the typical structure of an existing large organisation. It introduces a new coordination process for the middle layer. The top layer of SAFe big picture is portfolio coordination, high-level queue management. Scrum, which is at it’s best in creating the dialogue between Clan and Market control, can be seen at the bottom.
SAFe removes projects that control individuals’ time, but is liberal in having old and new coordination roles in the middle management. This means that the proportion of the bureaucratic control is not reducing significantly. This is logical because of systemic conditions remain the same, or change slowly. When the need for coordination stays, the coordination stays.
SAFe actually takes granted that you need the various middle management roles. “We need to have people in roles (it doesn’t matter what their titles are) that can take a large initiative, break it into smaller initiatives, manage the small initiatives, and deliver them. You have to have that.” – http://www.ugilic.dk/blog/2017/04/interview-with-dean-leffingwell-about-safe/
To support the process, SAFe provides a wide set of Lean-Agile best practises to improve the ways of working. Good consultation often helps to get results, also with SAFe. However, there is the risk that the systemic conditions are not changing, and the change remains superficial.
Conclusion – two different local optimums
SAFe and LeSS target into two different local optimums, each having a consistent set of practises, structures, skills, technology and culture. This has an analogy to species in nature. Grass-eaters and predators have different combinations of characteristics.
SAFe is not aiming to reduce the Bureaucratic control enough to move the organisation away from the Traditional optimum. Instead, it tries to optimise the existing organisation by creating Lean-Agile programs. The project/program management is an old mainstream practise at this optimum.
LeSS aims to reduce significantly the Bureaucratic control. It provides a mutually consistent set of practises that move the large organisation to a new Agile-optimum. In next blogs we will write more about the characteristics of the two optimums.
Some references and further reading on topics covered in this blog post:
Scrum is a successful and widespread framework, but at some point almost everyone started to talk about scaling. Large organizations want to spread this miracle and Agilize everyone. Many consider agilizing large organisations as bad, and some say it is inevitable. In any case, opinions are often negative about “big Agile”.
But what exactly is being scaled when we talk about scaling in Scrum or Agile software development? It seems that most imagine growing something larger, usually the number of people, or painting everyone in fake Scrum colours. “I see task boards, task boards everywhere!”. :-)
Naturally, this triggers negative reactions from the Agile community.
“Why would you want to deliver and support a product with multiple teams, when one team is so much more effective?”
The first purpose of LeSS (Large-Scale Scrum) is actually descaling through organizational change. Descaling the number of roles, organizational structures, dependencies, architectural complexity, management positions, sites, and number of people. LeSS is not about scaling one team into multiple teams. LeSS is about scaling up Scrum itself in order to achieve organizational descaling. Just to be clear, looking for a scaling framework to “buy and install” and to organize lots of people for the sake of “painting agile or Scrum onto our big group”, is just plain wrong.
A major purpose of LeSS is to expose the pain of being large, wasteful, and slow.
Fake Descaling with Fake Small “Products”
Here’s a common thought that people have when they learn and like the idea of descaling, rather than “big Agile”:
Why should an organization scale up Scrum? Why not just have many independent Scrum teams, each dealing with their own product and own users?
This leads to a very important question: What should be the definition (or scope) of a product?
Bas Vodde, the co-creator of LeSS (Large-Scale Scrum), gave this nice explanation:
Having multiple ‘fake’ small products that don’t deliver any real value is not better. Neither is losing the overview due to many small products.
Contrast these situations:
Small independent products
We take the large product and split it into smaller ‘independent’ products, with a few dependencies. This is nice as smaller is better. However, now in the organization we’ll need to figure out which of the products the teams need to work on. So therefore, we’ll need to add “portfolio management” so that we ensure the teams work on the high value products.
Not only that, we have now dependencies between the products. These are outside the products and hence it is probably more difficult to see when they happen and harder to coordinate by the teams themselves. Thus, we’ll need to add some project/program management to ensure the features in different products are synchronized.
Where do we put all that. Probably a PMO which we’ll need to create for that.
Large product definition
Now, the alternative. We define product broader. This means we’ll more quickly end up with LeSS Huge… but… we don’t need any additional portfolio management nor any project/program management to deal with all the organizational issues and different resource allocations :)
Though, we have a large-scale product… all these things are managed within the LeSS framework and … thus actually much less complex. Less roles, less management and a better overview.
Hence, we prefer a broader product definition, unless the products are truly independent products
A similar comment could be said about users and customer, since they are very much connected to definition of a product. A team dealing with a fake small “product” is likely to have fake users. “Our user is another product, and our customer is an IT application manager”. Or even worse, “Our user is the QuotingEngine,” where the so-called “products” are just architectural components, and other components are fake users. You don’t make any money from another internal component!
How LeSS Helps in Descaling
Just like Scrum, LeSS removes your organizational band-aids that apparently solved the problems, but actually masked them and didn’t address the root causes. “We have a quality problem, let’s create a quality manager, and then the pain is gone… for now.” Scrum is a band-aid removal system on a team scale, while LeSS is a band-aid removal system on a multi-team and organizational scale.
With LeSS, transformation happens along two dimensions:
1. Do the right thing and always the most important thing
Create organizational flexibility to always work on the most important goals from the overall customer-perspective product level, based on recognizing a world of learning and change. LeSS replaces big-batch and rigid portfolio management practices and decisions, where investments are matched to objectives, often for a year or even longer. The traditional project and portfolio management model also implies a fixed allocation of teams to specific programmes and projects, also for a long time.
In contrast, an example of the LeSS solution is one Product Backlog and one Product Owner for a whole product. Based on feedback and learning, a Product Owner can change direction and assign new goals with increased flexibility at a low cost of change, since teams are not fixed within boundaries of projects and programmes.
2. Do things right
Each cross-functional feature team grows capability and responsibility for taking care of the whole value stream. Ideally, all teams co-create and maintain value together with the end-customer. The Definition of Done is far-stretching and all teams deliver each Sprint one single potentially shippable product increment for all involved teams. The foundation for this is made up of technical-excellence practices such as continuous integration, ATDD, TDD, etc.
Descaling Roles, Structures, and Workforce
During a LeSS adoption, along both dimensions of “do the right thing and always the most important thing” and “do things right”, it becomes painfully evident that parts of the original organizational structure are not needed. For a single product, a LeSS organization does not need portfolio, programme, or project management. It does not need a separate analysis, architecture, UX, or QA/test group. It probably does not need a separate operations group.
In LeSS, the basic organizational building block is the cross-functional and cross-component feature team. Most people will simply become regular members of feature teams, delivering running, tested features and a shippable product every Sprint. It’s very simple. There are no fancy titles, no release trains, no layers of management. But some people will also leave because they do not fit in this new value-driven organizational structure that emphasizes hands-on making solutions over status and “managing”.
We often have a gut feeling that there’s untapped potential: what if our organisation can create value with fewer teams, or even with a single team? If that possibility is present, how would we know what to look for? LeSS gives us the means to see this potential, and act upon it.
A goal of LeSS is to create a learning organization with a high level of collaboration and knowledge sharing through communities and other means of coordination. This is important to prevent duplication and the potential architectural chaos of having many empowered but potentially disconnected teams. But a learning organization doesn’t happen overnight. An organization that grows this culture, driven by the LeSS framework, will take time.
In short, LeSS is a scaled up Scrum framework, which enables descaling of the organization.
RSS feed