As per Scrum Guide, “…Scrum is a framework for developing and sustaining complex products… It [Scrum] is lightweight, easy to understand and difficult to master”. The guide talks about basic Scrum, or Scrum by one cross-functional team that works for only one Product Owner, on one single product. The guide also mentions situations when multiple Scrum teams must work on the same product backlog and share the same Definition of Done (DoD) – an example of scrum scaling.
Large-Scale Scrum (LeSS), is a product development framework that extends Scrum with scaling rules and guidelines, without losing the original purposes of Scrum.…”. Some of the hallmarks of LeSS are:
- It is the framework that requires organizational de-scaling (simplification), to scale basic Scrum
- It is the framework that strongly relies on effectiveness of organizational design and system dynamics of multiple organizational layers, departments and spheres of control
- It is not merely a group of teams doing their own Scrum, while working for different product owners and supporting different products. Rather, it is a group of teams (2-8) that works together, synchronously, on the same product and serves the same product owner.
It is worth stressing the last bullet point above:
Frequently, novice agile adopters mislabel scrum implementation by independent and unrelated teams, as “LeSS”. Sometimes, they are genuinely mistaken. But there are instances of intentional LeSS terminology overload. In either case, inappropriate use of LeSS terminology creates asymmetry between LeSS guidelines and rules, on one hand, and reality of teams’ working dynamics – on the other.
Another prevalent misconception about LeSS (and more on this later in this post), is that LeSS postulates are ONLY applicable in large scale settings. Some, less experienced agile practitioners feel that if an organization implements Scrum in its basic form only, without attempts to scale, the facing organizational dysfunctions that are vividly exposed by LeSS, could be avoided. This is a mistaken belief: LeSS principles can be used to improve basic Scrum as well. Practically, any organizational dysfunction that is exposed by LeSS, also presents a challenge for basic Scrum, but perhaps, in a form that is not so obvious, and with a manifestation that is not so disturbing. In a way, LeSS serves the purpose of “dysfunctions amplifier/magnifier” that allows seeing more clearly, at scale those things that may not be as obvious at single team level.
Below are the six big topics (LeSS “Hexagon of Values”) that are always brought up in LeSS discussions. Lets take a closer look and see if they still retain their relevance in basic Scrum:
Feature Teams over Component Teams
From LeSS perspective:
From a stand-point of a paying customer, feature-centric product development is the most effective way maximize business value. Feature teams can perform this work best, since they are able to operate across multiple application components, independently and autonomously. Component teams cannot do the same. A component team is focused only on one single application domain that is not shippable (marketable) on its own, if viewing from a standpoint of paying customer. Trying to fake LeSS, by putting under the same wrapper multiple component teams, creates a large amount of handover and other procedural overhead before a release. For example, if eight component teams (max. # in LeSS) work only on respective single component items, pulling them from the same backlog, there will be a lot of component integration required, before a product becomes truly shippable (PSPI). This will either, at best, consume a lot of teams’ capacity at the end of each sprint, or will require an additional “hardening” sprint before going to production (at worst).
How is this applicable to Basic Scrum?
It is not uncommon to see single component team that pretends ‘doing scrum’, by introducing scrum roles, artifacts and events to their work model. At a glance, it may appear that a team does what other scrum teams do – it sprints, but the goal of scrum: to deliver PSPI – is still absent. The impact of such faking, on the ability to meet a product owner’s goals may not be as strong and obvious, because delivery expectations from a single team just are not as high as expectations from 8 LeSS teams. (Another word, from a standpoint of time & resources spent and humans involved in performing work, a single component team that pretends ‘doing scrum’ would have an easier time to justify to a product owner and stakeholders ‘why’ their end-of-sprint deliverable is not shippable: justifying ‘undone’ work by 3-9 developers of basic scrum is just easier than justifying ‘undone’ work by 50 developers of LeSS). However, the core underlying problem still exists in basic Scrum: a sprint deliverable is not PSPI.
Component Mentorship over Component Ownership
From LeSS perspective
There is a distinction between Component Ownership and Component Mentor-ship:
Component Owner – is an individual (sometimes, a group) that has unique privilege to work on a particular application component. If any other team needs to make modifications to a given component, they must delegate this work to a component owner. Rarely, these ‘private code policies’ are justified by external regulatory requirements or internal audit needs. More frequently, such ownership is due power retention and sphere of control ambitions of certain individuals/groups, both being secondary to internal organizational politics.
On the other hand, Component Mentor – is an individual that has a lot of work experience with a particular component, but instead of becoming a bottleneck to component-specific work, he teaches others how to do the same. Effectively, a component expert becomes a teacher of “how to fish”, instead of a giver of an “already caught fish”. With such approach, any feature team, over time, becomes proficient at working on any application component, without being dependent on a component owner: each component becomes a shared property; no more someone’s private and protected domain.
By giving up the privilege to be the only person who can touch an application component, an application mentor should not lose his organizational value: instead of being a single-contributor/performer he now becomes an educator and advisor – the role that is much more scalable in large organizational settings. This empathizes another concept (below) that is strongly advocated by LeSS trainers and coaches: Job Security should not be confused with Role Security.
How is this applicable to Basic Scrum?
Perhaps, the most important distinction in basic scrum is that for a single-team operation, the benefit of having experienced and willing to share their knowledge with others, component mentors, is not as obvious. Also, an organization may have a hard time to justify designating a component mentor, per component, serving a stand-alone and unrelated to others, scrum team. But even for a single team that does basic scrum, the problem still remains: not being able to work directly with certain application components will continuously lead to having external dependencies on other teams/individuals, and therefore, will put at risk the ability to deliver PSPI at the end of each sprint.
System Optimization over Local Optimization
From LeSS perspective:
There is strong contrast made between Local Optimization and System (Global) Optimization. Any single-specialty department (UI/UX, BA, QA, Dev, DB) is ‘locally optimized’. This means that people within each department might be very busy and work hard to complete a series of tasks that ONLY they can do. The opposite is true too: a group of single specially workers can perform ONLY a subset of tasks that their skillset allows. While from their own (local) perspective, they work very devotionally and produce a lot of output, from a stand point of a paying customer, the overall outcome is still low. False perception of local efficiency by single-specialty workers does not directly translate into system efficiency: individual ‘local progress’ does not add up to system progress. A classic example of local efficiency could be over-production of comprehensive BRDs by Business Analysts (BA), way ahead of development efforts: while from a stand point of BA, lots of great documentation is produced and signed off, from a stand point of a paying customer, much of this work may become obsolete (projects are delayed, priorities change, budgets get cut, etc) before implemented in code.
How is this applicable to Basic Scrum?
Manifestation of local optimization, also being a direct result of single-specially (component) work, is frequently seen on basic scrum teams that lack T-shaped developers. For example, non-technical business analysts and manual testers, will be, most likely, focused on ‘writing stories’ and producing manual test cases, respectively, way ahead of sprint development. For example, is not uncommon to see BAs, attempting to ‘clarify’ user stories by adding to them a lot of conventional, contractual documentation (e.g. BRDs) that leads to reduction of communication with a product owner and stakeholders during sprinting; this introduces elements of mini-waterfall in scrum.
Job Security over Role Security
From LeSS perspective:
Any person should have a job and be capable of making living. Offering job security to each employee, should be one of the most important goals for any organization. However, job security should not be equated to role security. Gradual changes of needs in any particular role, could be a natural process that follows bigger industrial changes: modernization, computerization, robotization, etc. Efficiency an overall system organization should not be sacrificed for preserving specific roles that no longer bring value.
One of the most common role changes discussed in LeSS is the role of Project Manager (usually, first-line PM). Scrum requires self-organized and self-managed teams that take full responsibility for their own work and interaction with customers. Everything is done by a team that performs work: work estimation and assignment, ownership and information sharing, communication and reporting. Historically, all of this has been handled by a project manager. Shifting all these responsibilities to a team, makes PM feel underutilized, sometimes annihilated. In environments, where teams no longer require tight managerial control, managers may have to re-focus on removing organizational challenges that teams face and cater to teams everything, what is required, to optimize team work.
It is critical that any organization that reevaluates its existing roles, also takes a close look at existing job families and employee career paths. If an organization suspects that some employees might be displaced due to changes of roles and responsibilities, it must provide other alternatives for people: education, training, internal mobility to other parts of an organization, etc.
How is this applicable to Basic Scrum?
The need to provide job security for potentially displaced workers in basic scrum settings is no less important than in LeSS. Business analysts and manual testers should be given an option to move into scrum teams and learn additional skills. In basic scrum, unlike LeSS, where there is a much stronger need for addressing and resolving organizational impediments, it could be less obvious how a first-line manager of a single scrum team can be fully occupied, with removing impediments, as this is usually Scrum Master’s responsibility (in basic scrum, at single team level, impediments may also be not as systemic). In such cases, line managers should be given an option to move to another part of an organization, where traditional development is still practiced.
Narrow & Deep over Broad & Shallow
From LeSS perspective:
When it comes to large-scale agile adoptions, it is very easy to develop a false assumption that bigger is always better. Some organizations are trying to jump on a bandwagon of agile-mania and claim early victories (this is often caused by ill-defined motivation and bonus schemas that praise people for achieving certain fabricated goals, e.g.: by ‘rolling out agile’ to a very large part of an organization. Such attempts of broad coverage also lead to shallow impact: organizations are able to demonstrate short-term superficial (sometimes, fake) results but there is not enough momentum to ensure continuity and long-term success.
It is always much better to focus on a narrow part of an organization, by extrapolating it from a larger organizational construct, and improving organizational agility, by going deeper into organizational structure. In LeSS, the recommended size of an organization (at least, on technology side) is about 50 people.
How is this applicable to Basic Scrum?
This concept is probably not as applicable to basic scrum, as other concepts mentioned so far. ‘Breadth’ of implementation implies wide organizational areas and involvement of many people. Basic scrum is not as concerned with horizontal span of efforts because, by definition, a scrum team is only 3-9 people.
Owning over Renting
From LeSS perspective:
When it comes to making decisions, organizations and teams should look for ways to develop their own approaches, instead of ‘copying & pasting’ solutions of others. Relying on professional trainers, is a great way to learn from expertise of others, in classroom settings. Leveraging help of professional coaches, is another, longer-term, way to mature, through self-discovery, experimentation, inspection and adaptation.
Organizations and teams should be striving to own their own decisions and take responsibilities for successes and failures. On occasions, trainers and coaches may lead by example (e.g. mock-up a behavior of a specific agile role), share lessons learned from prior engagements, but this is not done to encourage customers to copy/paste approaches and styles. Ultimate decisions should be always made by those that will live with those decisions in a long-term.
How is this applicable to Basic Scrum?
In basic scrum, just like in LeSS, teams are expected to leverage what they have learned from trainers and coaches, to gain autonomy and become owners of their decisions and solutions. Through frequent inspection and adaptation, teams that work in basic scrum should be able to ultimately modify their processes, as needed. Logically, it would be also expected that a coach who assists team (s) that use basic scrum, coaches ‘himself out of work’ sooner than a LeSS coach, since organizational design challenges have much more severe impact on LeSS team that on basic scrum teams.