(Bas Vodde and Craig Larman)

More with LeSS: Simplifying Organizations with 7 Design Principles

Why adopt agile or LeSS? Unfortunately, many organizations aim to increase individual or team productivity, activity, outputs, velocity, or resource utilization without realizing this usually leads to lower overall value delivery, longer cycle times for customer features, and less adaptiveness. LeSS does not focus on local optimizations such as increasing individual productivity, but on optimizing an organization for maximizing customer value delivery and organizational agility (adaptiveness)—the ease, speed with which an organization of people can change direction based on learning.

How to achieve agile, flexible, adaptable organizations? By creating simpler organizations!

Complicated organizations with many roles, processes, departments, and artifacts are slow to adapt to changes. Simple organizations have the potential to adapt quickly. In the LeSS community we refer to this as descaling organizational complexity. It is the essence of one of the LeSS principles, the More with LeSS principle.

How can we design simpler, agile organizations? We use the following organizational design principles to descale into LeSS organizations:

1. From Specialist Roles to Teams
2. From Resource-Thinking to People-Thinking
3. From Organizing around Technology to Organizing around Customer Value
4. From Independent Teams to Continuous Cross-team Cooperation
5. From Coordinate to Integrate to Coordination through Integration
6. From Projects to Products
7. From Many Small Products to a Few Broad Products

1. From Specialist Roles to Teams

Traditional organizations have single-specialized roles and elaborate processes on how these roles ought to interact. Individuals are responsible for their individual specialization. They are hired for that and might spend their entire life in that area of specialization. When all individuals perform their defined role, the organizational performance is maximized, in theory. Adaptiveness is likely to be low.

LeSS organizations have teams that have a shared responsibility for achieving a customer-centric goal, by self-managing—they themselves decide how they work and who does what. Team members are not stuck in the false dichotomy of being a generalist or a single-specialist. People naturally have preferences, yet they are not limited to a single specialization. Many specialist roles, such as tester or interaction designer or business analyst, cease to exist as these responsibilities become team responsibilities. Broad responsibility and self-management increase adaptiveness.

2. From Resource-Thinking to People-Thinking

Traditional organizations manage people as resources, assuming the skills of individuals are relatively fixed. They are structured to maximize the utilization of these resources against the goal of increasing individual productivity. This requires significant management effort to resolve these complicated resource allocations.

LeSS organizations manage people as people and assume that the greatest skills of individuals are acquiring and developing skills. LeSS organizations are structured to purposely cause a mismatch between existing skills and knowledge and those needed, for the benefit of increasing adaptiveness. This requires people to learn, which causes both joy and discomfort… but all the complicated resource management disappears.

3. From Organizing around Technology to Organizing around Customer Value

Traditional organizations structure their organization around their technology. Many people identify themselves with their technology specialization and organizing around this seems to maximize their individual productivity. Delivering customer value often requires more than one technology and that causes additional coordination effort and reduced adaptiveness.

LeSS organizations structure their organizations around customer value. Deep understanding of customers is essential for solving their problems using technology. Bringing teams close to customers by organizing them around customer value increases this understanding and leads to greater adaptiveness and more customer value.

4. From Independent Teams to Continuous Cross-team Cooperation

Traditional organizations prefer independent teams that can focus on their part of the product. These teams avoid continuous interruptions by specifying well-defined interfaces to which other teams must adhere to. Change, review, and approval processes avoid frequent changes to these interfaces. Often independence is achieved by hiding and delaying genuine dependencies. This isolation of teams reduces organizational flexibility.

LeSS organizations prefer multiple teams with shared work. These teams continuously cooperate to contribute to one consistent product. They function like one larger team, even though each team has their goal and own identity. Change, review, and approval can be greatly simplified or even disappear.

5. From Coordinate to Integrate to Coordination through Integration

Traditional organizations coordinate to integrate the output of many teams. Because the teams deliver their outputs asynchronously, the coordination responsibility is external to the team, leading to coordination roles (such as project and release managers) and coordination events. Coordination conflicts are common, leading to re-evaluating and shifting priorities.

LeSS organizations have teams that continuously integrate their work. Through continuous integration the teams discover opportunities for cross-team collaboration—a surprising and powerful idea. Because of the synchronous nature of cross-team integration—the teams have shared work right now at the same time—the coordination responsibility can be integrated into the team. External-to-team coordination roles disappear.

6. From Projects to Products

Traditional organizations manage development as projects or programs—big projects. Projects have clear start and end dates, clear scope. People are allocated to them for a predetermined amount of time. Budgets are decided by the expected value of the predetermined scope. This leaves little room for responding to changes. Myriad and varying projects cause complicated project portfolio management to synchronize the re-allocation of resources to projects.

LeSS organizations manage development as products. Products have a clear purpose but no fixed end or scope. People are allocated to them for an undetermined amount of time. Budgets are decided by potential value without tying it directly to a specific scope. This leaves lots of room for responding to change. A product is continuously developed and therefore a regular rhythm of re-allocating the people to products will suffice. Complicated project portfolio management disappears.

7. From Many Small Products to a Few Broad Products

Traditional organizations prefer managing small technology-based products such as services, components, applications, or platforms. But no such small product is an island and they need to interact and be integrated together to deliver customer benefits. This leads to complicated cross-product management structures for coordinating, prioritizing, and budgeting.

LeSS organizations prefer managing broad customer-centric products. The services, components, applications, and platforms belong to one product with one Product Backlog and one Product Owner. Teams create customer-centric features and work across these components. Complicated portfolio management disappears, and complicated cross-product management structures disappear or become significantly simpler.

Each organizational design choice requires a significant shift in organizational thinking and they have a large impact on people, teams, organization structure, and management. These changes aren’t always easy but they lead to simpler, adaptable, purposeful, and more fun organizations that deliver higher value.

That’s not my job!

This is a story from a colleague who was providing technical coaching at a client.

He was one of the technical coaches working with 40 Scrum Teams to improve on their technical, development practices and bring them on a par with 21st century standards.

At one of these sessions, the technical coaches provided training, mentoring and coaching about modern development concepts like test-driven development (TDD) and acceptance-level TDD (ATDD). One of the involved developers went to his desk, opened his drawer, pulled out his working contract, pointed at it, and said: “It does not say ‘testing’ in here.”

Clearly, that developer was heavily relying on his paper contract. If it didn’t state to wash his hands after he went to the toilet, maybe he wouldn’t have done so. Who knows?

But, seriously. Does it help if an idle team member points out that something is not his or her job, while the work needs to get done, and all the other people involved are too busy to do it? Not really.

Taking a closer look at companies large and small, we see a particular pattern. In smaller companies, it seems to be more like an accepted behavior to take overwork, even though it may not be part of your job description. In larger companies though, people are more hesitant to do so as the likelihood of stepping onto someone else’s toes might cause problems, not to mention that it often doesn’t help them advance their career.

Regardless, we don’t think the latter attitude is helpful to solve the complex problems we typically intend to solve with Scrum.

As humans, we are born with little skills. One of the core things the human brain is capable of learning new things, continuously and life-long. We learned to crawl, to step up, and to eventually walk and run. This freed us from the perceived problems when we grew up. Just because something is not your job should not keep you from learning the necessary skills to perform the work if it has to be done.

What if that work does not have to be done? Well, why then do it at all?

As humans, we learn all our lives long. That’s what distinguishes us from other species. Use that one thing that makes you human to contribute to your team’s efforts, meanwhile also developing yourself.

“That’s not my job” really is a pretty cheap excuse for not doing the related work. Don’t go there as it undermines team morale and your self-development.

(taken, and adapted from Save our Scrum)

Digital tools considered harmful: Jira

At the time of this writing, Jira is probably the most widely used digital tool in Scrum and LeSS adoptions. Unfortunately, using Jira commonly leads to some predictable dysfunctions. Some of these are:

• Scrum confusion and tool-owned processes
• Micro-management due to integration of Product and Sprint Backlog
• No shared team responsibility due to poor Sprint Backlog

Scrum confusion and tool-owned processes

Many companies start “enterprise-wide” Scrum adoption with mandating Jira. People learn Scrum through Jira, or so they think. However, Jira was never a Scrum tool. It is an issue tracking tool with many ideas integrated into it, such as Scrum and many… not-Scrum. Teams end up adopting ideas that they think, or were told, are included in Scrum.

The overall result is anti-Scrum. How? Scrum has a minimum of prescriptions as it implements empirical process control. Team practices are not prescribed or fixed but are adopted and adapted as context changes. Scrum implies team-owned processes rather than tool-owned processes.

Micro-management due to integration of Product and Sprint Backlog

Jira integrates the Product and Sprint backlog. This might seem like a good idea but in practice, it is not. It leads to confusion about their purpose.

The Product Backlog contains items that represent product features or improvement work. The Product Owner uses the Product Backlog for tracking product progress, deciding features to create next, and for making scope/time/cost trade-offs.

The Sprint Backlog is a plan from the Team on how they are going to attempt to achieve the goal of the Sprint. It is valid for one Sprint – it is created at the start of the Sprint, never earlier, and ceases to exist at the end of the Sprint. The Team keeps it up-to-date all the time. It enables them to take a shared responsibility and manage all the in-Sprint work.

Integrating the Sprint Backlog and the Product Backlog easily leads to the Product Owner and management starting to track in-Sprint progress. By doing so, they take over the responsibility of the Team to manage their own progress during the Sprint. The temptation to interrupt the Team during their Sprint is often irresistible. And this will change Scrum from a framework for supporting self-managing teams to a micro-management framework.

No shared team responsibility due to poor Sprint Backlog

Good teams avoid having half-done items at the end of the Sprint. They do so by truly taking a shared responsibility and by working one (or a few) items at the time. They achieve this through fine-grained task splitting so that each team member can pick up tasks related to the same item at the same time.

Creating tasks in Jira is slow. This might be because Jira itself is slow – most of my experiences with Jira were self-hosted installations (due to cloud restrictions) and they were all slow. Or it might be because tasks are created in Sprint Planning with one person typing. Whatever the slowness reason, all teams I’ve observed minimized their Jira typing time by avoiding small tasks.

Large tasks lead to less shared work, which leads to less shared team responsibility, which leads to a less effective team. How do you know this might be happening? Half-done items at the end of the Sprint and the Team talking about ‘spill-over’ or ‘carry-over’ work.

Key point: The phrases ‘carry-over’ and ‘spill-over’ are not Scrum. They’re signs of dysfunctional Scrum.

We are stuck with Jira, now what?

How to use Jira so that it causes the least amount of harm? My recommendations are:

• Never use Jira for Sprint Backlogs
• When using Jira for a Product Backlog, simplify it. Make it work like a spreadsheet.
• Avoid any complicated features and avoid workflows. Out-of-the-box Jira is already too complicated.

Digital tools considered harmful: Sprint Backlog

It is unfortunately common to use a digital Sprint Backlog. I explicitly say ‘unfortunately’ because of the negative impact a digital Sprint Backlog tends to have on team dynamics and collaboration. Using a digital tool for a Product Backlog might also be common but is less harmful. Digital Sprint Backlogs should be avoided!

I’ve observed four causes of digital Sprint Backlog,

1. The team is not co-located.
2. Management mandates a tool for Sprint Backlog.
3. The team uses a computer during Sprint Planning.
4. The Scrum Master adds tasks to the Sprint Backlog.

Each cause is a reflection of a team or an organizational dysfunction.

1) The team is not co-located

Dispersed teams are common as many companies pretend co-location doesn’t matter and allow organizational stupidity to disperse the majority of their teams. Check out my article related to this, called “co-location still matters!”

Dispersed teams frequently end up quickly deciding to use a digital Sprint Backlog. Yet, I’ve known quite some teams that manage fine with post-it Sprint Backlogs, white boards, video and photos.

2) Management mandates a tool for Sprint Backlog

Although I have often inquired about the benefits of ‘harmonizing’ the Sprint Backlog tool, the reasons to do so are still unclear to me. The most common response is a desire for better in-Sprint progress tracking. This is a clear sign Scrum is being misused for micro-management purposes as in-Sprint progress tracking is the responsibility of the team. Another frequent response is to derive metrics from the Sprint Backlog, but the metrics for tracking team progress and release management are derived from the Product Backlog and not from Sprint Backlog.

The Sprint Backlog is for the team; not for the Scrum Master or for the Product Owner, and definitively not for management. It helps the team to take a shared responsibility and to manage their work toward creating a releasable product Increment. What tool (or not) to use is the decision of the self-managing team. Management that mandates a tool doesn’t seem to understand Scrum and how it is founded on self-managing teams. That is the real problem to solve.

3) The team uses a computer during Sprint Planning

Computers cause boring meetings. They centralize discussions with the typing person becoming a bottleneck. Computer-centric meetings are life-sucking events and waste people’s time as they stare at the ceiling while waiting for the typist to finish.

Computer-less meetings can be much more productive and fun. Meetings automatically decentralize when the focus is on conversation and using cards or post-it notes to invoke collaboration. Everyone writes in parallel. Sub-groups emerge and later merge again. And the cards on the table provide an overview of what was done.

Sprint Planning is shared software design and ought to be fun!

4) The Scrum Master adds tasks to the Sprint Backlog

Scrum Masters who touch the Sprint Backlog will own it and they become fake-Scrum Project Managers.

Example: Non-digital Sprint Backlog

Following is a non-digital Sprint Backlog from a team I worked with.

This Sprint Backlog is the software design of the system, with the black boxes representing the current system and the red ones the envisioned design for this Sprint. The post-it notes are the tasks needed to do. This is the ‘to-do’ column of a task-board Sprint Backlog.

I’m not suggesting that your teams should work this way. This is how this team worked, they owned it. That is the most important reason for never using digital tools for Sprint Backlog. When using a digital tool, the tool determines the way the team is working. Without digital tool, the team can own and improve their own way of working.

Co-location still matters!

It is 2019 christmas. Will you skip the traditional family visit in favor of remote communication technology?

“Dispersed teams is the reality that we have to deal with!” is a common reaction when people discover that the LeSS rules includes “each individual team must be co-located.” Do we need to accept that as reality?

Many claim that modern communication technology has made co-location irrelevant. This is not my experience. Although it is certainly possible for a dispersed team to become high-performing, a typical co-located team still performs significantly better.

A co-located team, where team members are sitting at the same table facing each other, has the potential to be fun and effective. But what makes co-location better? It is the face-to-face conversations that speed up building the high-trust environment required for taking a shared team responsibility. It is the dynamically emerging discussions. It is the unknowingly, accidentally overhearing of a conversation and then suddenly contributing an essential fact to it.

Co-location does matter! It’s impact can be huge.

There are many factors that impact team performance which are not included in the LeSS rules, so why include co-location? Because after exploring the reasons for having dispersed teams, we concluded the most common one is organizational stupidity. Nobody ever bothered to try to co-locate the teams. The most common scenario is where someone high up in an organization decided to have half of the development to be done in a low-cost location. Instead of then designing the organization to maximize co-location, that decision is propagated as a rule through each layer of the organization. The result is that every team becomes a dispersed team. Organizing the same people differently could have resulted in only co-located teams, for the same cost.

Another common reason for dispersing teams, beyond organizational stupidity, is that certain skills are only available in certain locations. This might be a valid reason when acquiring these skills relate to being at that physical location, such as being close to a customer. More often, it an excuse to avoid other teams having to learn that skill. If that location is truly important, it might be worth having a whole team there.

It is always possible to co-locate every team? Perhaps not. But by having co-location included in the LeSS rules, we hope organizations stop accepting dispersed teams as an unchangeable fact and instead put thought and effort towards co-locating teams. It will have an impact on the team and the development.