A hot topic in HR and Management I’ve encountered a number of times is “employee engagement”. In fact, according to Delloite’s Global Human Capital Trends 2015 survey, the most important problem and trend in HR is “Culture and Engagement”. The problem of lack of engagement isn’t new. The surveys related to employee engagement exist since the late 1800s and were even used by Frederick Taylor to study people’s attitude. So called “soldiering” phenomenon Taylor observed in his studies is that monotonous work had negative effects on motivation and engagement.

Today, many employees still see work as something that has to be done without caring too much about it. When I mention “You should have fun at work and enjoy it at least as much as weekends and vacations” I’m usually replied with cynicism. According to a Gallup’s survey, only 13% of employees are “engaged”, while others spend their valuable energy and time on e.g. Facebook during the work. More seriously: 64% is not engaged and additional 24% is actively disengaged.

Leadership is often given as the answer with the believe that it has a positive effect on engagement. There is, in fact, no significant research that proves this. Cesario Ramos explains in his blogpost these misconceptions, backed by several scientific sources.

There is a tendency to overemphasize the importance of leadership and overlook more important systemic problems in environment people work.

What effect does LeSS have on employee engagement?

The meaning of “engage” isn’t clear and engaging itself shouldn’t be the goal. Instead to create exciting, fulfilling, meaningful, and fun environment. Organizational structure in LeSS supports creating such environment:

Customer Centric and Whole Product Focus principles create purpose

Refocusing employees engaged in product development toward whole product and actual customer instead of local part or a local activity helps in making work purposeful. It answers the question: “Do I contribute to a whole product and therefore customer value?”. This is particularly important in large product development, where it is common to feel lost or irrelevant.

Some people are satisfied with their work without having a whole-product focus. How? They optimize what is in their control and this often leads to local optimization. For example, the system architect tries to manage all complexity but has this nagging feeling: Did my contribution really work out? Even more present is constant tension with other people involved in same product development. It looks as if there are many separate goals, instead of delivery of a single product.

People want to see an own contribution to have a positive effect for someone else, the customer. One needs to see this effect as frequent and clear as possible in order to get out of bed for more than only a salary and possible bonus.

This sense of purpose can be achieved by having a clear product definition and product vision. All team members are involved in this. This is usually during a workshop such as Product Vision Board, Product Vision Box, User Story mapping.

From there, the constant reminding of the product vision happens during Product Backlog Refinement where team members engage directly with users, customer, and other stakeholders. No matter the size of the product. When we compare LeSS to Scrum, LeSS ensures strong collaboration between teams and customer / stakeholders by having one PO for a whole product. Not one PO for each team as then the PO often stands in between users and the teams.

Therefore, teams see the achieved value via the quick and direct feedback received from customer / stakeholders. No “translator” such as BA, Product Owner, (Project) Manager, Architect in between.

Developer’s job enriched

Great developers today do not stare at their screen and avoid people. Not much of these jobs are left, and it is unlikely to improve in the future. Working alone implies a lack of sharing and lack of shared responsibility. The effect is that code and (automated) tests tend to become unreadable for others. The job is exciting and powerful (“I’m important to others”) in the beginning until it goes into production and everyone wants something from this single developer. This creates stress and frustration since there is no one to help out.

The job of a developer isn’t just writing code. Not even just writing quality code. The job of a developer includes continuous integration and test automation. But that is not it. Even requirements are part of a modern developers job. A big chunk of the time developer collaborates with customer, stakeholders and other developers.

“We hate meetings. Period!”

Meetings are passionately hated. They are dreadful, long time-slots, stolen from a developer by someone “more important”. And they always come too late. The goal of most meetings is unclear and people boast while you wonder “why am I here?”.

Despite this passion, the problem is usually not meetings in general, but the lack of involvement and empowerment to influence and decide what happens in the meetings. LeSS supports effective collaboration and meetings help achieve this. The people who hate meetings do get together, share, discuss, and make decisions…together. In other words, they do meet but don’t call them meetings.

Most developers I meet do not like large product developments (except salary part :-)). Why? It isn’t because they are large. Not because their products are insignificant as they are often important products with nice challenges and impact. But it is because there are so many wasteful activities between own work and creating value that effect of own work is much less visible.

Luckily, in my experience, there is hope! In a LeSS organization, the job becomes more meaningful, powerful, and circle of influence is significantly larger. And meetings become fun! They become places where creativity happens, complex problems are solved and continuous learning nurtured.

In a product group adopting LeSS, a developer can influence not only what happens within the boundary of her own team, but also cross-team and whole product. This is what creates a fulfilling work environment.

Manager’s job enriched

Managers often ask the question, “If I’m not supposed to decide what people should be doing, how they execute their work, then there is not much left for me to do. In the best case, I don’t really know how to do my job without this.”

Why would managers think this?

Organizations have often pushed the manager into a position where the manager is the one who makes things happen by defining what needs to be done, how the work is done and supervision. There is also a tendency to look up to e.g. Steve Jobs or Elon Musk as role models. But they misinterpret their importance. Despite all leadership or what I call “humbleness” training, if you as a manager are the one accountable and responsible for everything that happens on your team you will be skeptical about self-management.

Most managers involved in LeSS adoption find the change positive. The reason for this is found in their actual job before the change. Ironically, in strongly hierarchical organizations middle managers tend to be very busy doing not so inspiring work. E.g. yearly performance reviews, budgets, objectives, KPIs, reporting, hiring and firing people, salaries, and bonuses. In fact, such managers tend to make long hours especially during the last months of the year, and beginning of the next one.

The more satisfying part of their job tends to be rather a minor part. The fun part of being a manager (besides a good salary and status :-)) is that manager supports, helps and teaches teams with their knowledge and experience. Managers should also create spacetime where people can learn, grow and excel.

LeSS principles, rules, guides, and practices help to simplify or completely remove many of the annoying practices. This creates more time for the manager to be meaningful to her teams. Instead of continuously and under pressure deciding what people should work on and how they should work, a manager is very visible and contributes by resolving impediments, pairing with team members, personal coaching, organizing events, open spaces, etc. A manager is also a matchmaker between people across departments and other groups of people. Therefore, in LeSS, the role of middle management is capability building.

Also, self-managing teams do not happen overnight. It takes time and effort to achieve this. Managers play a crucial role in the creation of this mindset by very actively delegating responsibilities to teams. In some cases although not recommended, managers become ScrumMasters, and sometimes go back to development and become valuable team members while still retaining all benefits. However it turns out for each of them, I never met a manager who was not pleased how the job changed after transformation, although the ride towards this point can be quite difficult.

Customer’s experience with IT people enriched

In large product development, customer satisfaction is often a sanity check. Customer dissatisfaction is a symptom of organizational dysfunction. Any improvement is not sustainable if it is not reflected in some way in customer satisfaction. In case there is a lack of it, a never-ending blame game between customer and IT guys is played. Unfortunately, this blame game becomes de facto standard after being played for years. It results usually in a complex contract game where situation stabilizes and the problem is covered up. The blame continues and nothing has really improved.

Although “Customer collaboration over contract negotiation” is embraced in Agile practices, it is often not reflected in the reality of large product development.

For a customer, one of the promises of Agile development is close collaboration with a team that is able to fulfill a need in an iterative and incremental manner. We are talking here obviously about a real customer need, and not so-called technical need. But, although teams on are so-called Agile teams, you can’t really talk directly to any of them.

Why not? None of the teams is able to deliver your wish on their own, and their focus is one application. In other words, part of the puzzle. They are component teams. A common example is corporate banking products that usually translate into a chain of many separate applications that need to be changed. Each of them is managed by a separate “Agile team”. A complaint from an internal customer I’ve heard a number of times: “I don’t even know who do I need to talk to about this”.

From the customer point of view, it becomes frustrating and impossible to be bold, try something soon, experiment cheaply, collaborate directly with developers. At that point, the customer tends to be cynical about the whole Agile thing.

In LeSS, this complex corporate banking need is the product or part of a product. Teams are organized around such a product definition, and since they are feature teams, each has the capability of making changes across many applications. The customer interacts directly with a feature team that is able to fulfill a need completely.

Collaboration in this context could mean:

• Discussions about idea and possibilities
• Doing experiments for one sprint and getting direct feedback on daily basis if needed
• Finding out how difficult would be to get product / feature delivered, and whether it could create value at the end.
• Delivering product iteratively, within few weeks or faster after having it prioritized by Product Owner.

This reduction of organizational complexity translates into the removal of the wall with IT people where blame game is reduced and contract game not needed anymore.

Conclusion

Therefore, LeSS has positive influence on engagement by:

Improving sense of purpose in large product development through principles of customer centricity and whole product focus Broadening developer’s circle of influence through decentralized decision-making and closeness to the customer. Enabling to take more meaningful work for people with role “manager” Seeing more satisfied customer.

This post is cross-posted from the Odd-e page at their blog

Decouple Line Organization from Requirement Area

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.

1. 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.
2. 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.

Interview with Venkatesh Krishnamurthy in CA DevOPs Perspectives. First published in DevOps Perspectives, edition 4

“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.

LeSS has been covered extensively in two books, and Krishamurthy highly recommends checking out Less.works and Scaling Lean and Agile Development.

This post is cross-posted from the Gosei page at their blog

Scaling Agility or Bureaucracy

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’s control mechanisms

Professor William G. Ouchi is known for his book “Theory Z: How American Business Can Meet the Japanese Challenge”. It introducing the principles of Japanese management to Western business audiences and stayed at US bestseller list for 15 weeks.

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:

• William G. Ouchi: A Conceptual Framework for the Design of Organizational Control Mechanisms, Journal Article, 1979, Management Science p833-48
• William G. Ouchi: Markets, Bureaucracies, and Clans, Administrative Science Quarterly, Mar 1980, v25 n1 p129-41
• Ralph Stacey: Complex responsive processes in organizations, ISBN-13: 978-0415249195
• Daniel A. Wren, Arthur G. Bedeian: The Evolution of Management Thought, 6th Edition, ISBN 978-0-470-12897-8