Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.
Experience Report by Guest-Blogger Ram Srinivasan
Experience Report by Guest-Blogger Mark Uijen de Kleijn
LeSS Graphic Art
Personal Memorable Moments
Next LeSS conference (2019) – Munich, Germany
Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.
More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.
With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum. It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework. On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.
Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner? Well…
- LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner. LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block. Understanding basic Scrum made understanding of LeSS very easy for everyone.
- The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like 😉, when coming in. Everyone in class was an educated customer. Importantly: there were no attempts to change LeSS (or change training content 😊 of LeSS), to make it better fit conditions of organizations, where people came from.
- Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.
The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)
One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many). And it goes as follows:
…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle). ‘Agile’ won because of the reasons that are described here. Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible. We all have to be careful with the meaning of words we use, to avoid this painful irony😉.
Here are some Kodak moments from the event:
Last week, at New York Scrum User Group (NYSUG) monthly event, co-facilitated by the agile coaches Dana Pylayeva and Emilie Franchomme, there were multiple agile games presented – all for different purposes and for all types of audience. Above all, what really stood out was the “Beautiful Meadow” game that helped with making a revealing discovery about handling business requirements. Below is the summary:
Team A and Team B, of 8 people each, were given the following drawing instructions (click on the image below to enlarge):
|Team A||Team B|
The requirements of Team A were very detailed, whereas the requirements of Team B were rather generic. Each team was given a set of color markers and a large flip-chart sheet. Both teams were allowed to review the requirements in silence – for 30 seconds. Then both teams were given another 60 seconds to draw a picture, based on given requirements, but they were allowed to collaborate in sign language only.
Observations and Results:
For the first 30 seconds of the exercise both teams’ dynamics were very similar: hurdling around the requirement, trying to understand it, orienting yourselves are around the canvas. Silently, some people seemed to volunteer to draw various elements of the picture. For the second 60 seconds interval, dynamics significantly changed:
At a glace, Team A seemed to be somewhere less organized and more hectic. People seemed to move around the canvas anxiously, trying to pull markers from each other’s hand. What also became obvious was that each person was trying maximize their contribution to the picture, by drawing in a silo, without much collaboration with others.
Team B, on the other hand, seemed to be much more organized and focused. Individual work of each person seemed like a continuity of someone else’s effort. Markers were effectively passed on from one person to another. There was much more collaboration and common effort here.
After 60 seconds of drawing, the teams produced two images, illustrated below: Team A – left canvas, Team B -right canvas (click on the image below to enlarge):
Team A has produced a picture that consisted of multiple disjointed elements that together did not seem to fit well. Oddly it even produced two suns – in two opposite corners of the canvas, whereas the instructions clearly asked only for one sun.
On contrary, Team B was able to produce a simple, coherent logical picture, with each element enriching the overall composition with additional relevant detail.
This exercise clearly demonstrated that too detailed requirements, passed on to a group of individuals, as one conclusive document, are executed much poorer than light requirements passed on to a similar group of people. In case of Team B, there was a request of “WHAT” to draw, not “HOW”. The team was able to use all of this innovation and artistic skills to produce what was required. Oppositely, team A was asked to delivery “WHAT & HOW” and the teams’ ability improvise on-the-fly was significantly reduced.
There were two sets of teams (two Team A and two Team B) and the results produced by the second set of teams were very similar to the case described above.
Relevant Article: Waterfall Requirements in Agile Product Development
Agile frameworks (e.g. Scrum, Kanban, XP), individuals’ roles & responsibilities, processes & tools, metrics & reporting, burn-up charts, estimation techniques, backlog prioritization, agile engineering practices, agile maturity models etc. – all of them are important attributes of a typical agile transformation. However, NONE of them are first-degree-of-importance system variables that are responsible for transformation success. Most of them, are good superficial lagging indicators of agility but they are all corollary (secondary and tertiary) to another much more important system variable.
What is the most important system variable that defines a company’s agility? It is Organizational Design – the most deeply rooted element of organizational ecosystem that defines most of system dynamics.
When organizational leadership decides to take an organization through an agile transformation journey (it could take years, sometimes), it [leadership] needs to acknowledge that real, sustainable agile changes are only possible if deep, systemic organizational improvements are being made. For that, leadership needs to be prepared to provide to its organization much more than just support in spirit, accompanied organizational messages of encouragement and statements of vision. Leadership must be prepared to intimately engage with the rest of an organization, by doing a lot of real “gemba” (genchi genbutsu (現地現物)) and change/challenge things that for decades, and sometimes for centuries, have been treated as de-facto.
What does it really mean for leadership to engage at System Level? First, it is important to identify what a system is: what are a system’s outer boundaries? For example, one of the most commonly seen mistakes that companies make when they decide on “scope of agile transformation” is limiting its efforts to a stand-alone organizational vertical, e.g. Technology – and just focusing there. Although this could bring a lot of local (to IT) success, it may also create unforeseen and undesirable friction between the part of an organization that has decided to change (IT) and the part of an organization that decided to remain ‘as is’ (e.g. Operations, Marketing). For example, if Scrum teams successfully adopt CI/CD, TDD or other effective engineering practices that enable them deliver PSPI at the end of every sprint, but business is not able to keep up with consumption of deliverables (too many approvals, sign offs, red tape) then the whole purpose of delivering early and often gets defeated. Then, instead of delivering to customers soon, in exchange for timely feedback, teams end up delivering in large batches and too far apart on a time scale.
A successful Agile Leader must treat an organization, that is expected to transform, as a sushi roll. Just like seaweed alone does not provide a full spectrum of flavors and does not represent a complete, healthy meal, one single department (e.g. IT) is not sufficient enough to participate in agile transformation efforts. Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment. A slice does not have be too thick. In fact, if organizational slice is too thick, it might be too big to “swallow and digest”. But still, even when sliced thinly, an organization must include enough layers, to be considered as a ‘complete meal’.
Note: A great example of treating an organization as a sushi role, while making it more agile, is Large Scale Scrum (LeSS) adoption.
So, what are some key focus areas that every Agile Leader must keep in mind, while setting an organization on agile transformation course?
- Location strategies. Geographic locations.
- HR policies (e.g. career growth opportunities, compensation, promotions)
- Budgeting & Finance
- Intra-departmental internal boundaries and spheres of influence
- Organizational Leadership Style
- And some other areas that historically have been considered as …untouchable…
All the above listed areas are defined by Organizational Design and can be better understood through self-assessment, done by organizational leaders at all levels.
When we ask an experienced Scrum developer what defines a good User Story, the answer we hear almost immediately is that “…every user story must be INVEST-able…(taken from B. Hartman’s post)”.
When we further elaborate on “INVEST” part, we hear that splitting user stories should be done Vertically (along features), not Horizontally (along components or applications layers). Why is the latter condition so important? Because when split vertically, and cross-cutting through multiple components, a user story has a much higher chance of representing a potentially shippable product increment (PSPI). Delivering, UI/UX alone, or business layer alone, or database alone, does not present value to a buying customer.
Frequently, we hear the analogy of a sushi roll, when describing story slicing: “…every User Story must represent thinly sliced sushi roll that provides taste and flavor of multiple layers (caviar, seaweed, rice, tuna, avocado, etc)…”
…Now, imagine an organization that is undergoing agile transformation. Predominantly (statistically), transformation efforts stem from Technology, where agile improvements come in the form of introducing good engineering practices, such CI/CD, TDD, unit testing, test automation, automatic deployments, etc. But technology alone, is just one layer of an organizational sushi roll. Sure, just like seaweed alone, it may be tasty enough for starters, but without adding additional flavors, it is not a complete, healthy meal.
Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment. A slice does not have be too thick. If organizational slice is too thick, it might be too big to “swallow and digest”. But still, even when sliced thinly, an organization must include enough layers, to be considered as complete meal.
What are some of those layers? Let’s consider a few:
Business & Operations: it is imperative to have real customers intimately involved in agile transformation efforts and making them closely aligned with technology partners. This requires identifying and providing a strong support for some key agile roles, such as product owner, stakeholders and SMEs. Often, this requires organizational realignment and changes to sphere of influence.
HR: Subjective monetary rewards that are based on individual performance assessments and fueled by invisible internal competition among employees, must be discontinued, in favor of incentives that promote teams’ collective ownership and performance. An organizational slice that wants to become more agile will have a much higher chance for success if HR policies were genuinely supportive of the initiative of the efforts.
Budgeting & Finance: For agile teams (Scrum, Kanban) that use adaptive planning and iterative development, and continuously have their work re-prioritized by business, it is imperative to have flexible budgets (“flexible spending”). By unlocking a rigid budget corner of what is known as Project Management Iron Triangle (budget, scope, timeline), technology dramatically increases their chances to do research or conduct new experiments, if an opportunity presents itself (often, unexpectedly). There is also a higher chance that more Scrum teams would be built out faster, if budgets were flexible and not done as ‘budgets against the wall’ (‘the world ends on December 31st’) – more flexibility to acquire new talent.
Real Estate & Facilities: Having agile teams co-located under the same roof is a huge win: e.g. Scrum team dispersed around the globe is not as good as Scrum team placed on the same floor. (Note: Please, do not confuse a single Scrum team spread thin across multiple locations with multi-site Scrum product development, when many, whole teams are collocated but separated from from peers-teams by geography).
However, putting a team on the same floor is not sufficient. Interior design must be supportive of team collaboration and dynamics: ‘caves & common’ (read A. Cockburn about XP), information radiation techniques (lots of whiteboard space, flip-charts), breakout areas, extra space to accommodate extended user community during sprint reviews, etc. – is all required. It is unfortunate but common to see so-called Scrum team members sitting in a long single row, next to each other, spear-headed by a line manager (usually, a window seat), all joining a daily stand-up call by phone (while sitting!) and ‘reporting on status’, while staring at an electronic story board on their respective monitors. Agile teams don’t want that.
As a summary, please consider the following quote that describes sushi-roll-like organizational design in Large Scale Scrum (LeSS), by C. Larman:
Why are there so many troubled agile “transformations”? We frequently hear the following answer: “because companies lack senior leadership support”. True. And let’s not trivialize this: without strong and genuine support by senior leadership (beyond slogans and “support in spirit”), without selecting a deep, systemic approach to problem resolution, companies can only expect localized, peripheral and, most likely, short-term improvements.
But is there anything/anyone else that can be conveniently held accountable for failed agile transformations?
How about ineffective agile training and coaching? [Note: If you are interested in learning more about some of the most common challenges with agile training, please visit this page. This post is about coaching .]
…There is a vicious cycle that hurts so many companies (can be also considered as a self-inflicted wound):
→initially, companies set a low bar for coaches, based on poor understanding of a coaching role → low quality coaches (quasi-coaches-“centaurs”) are hired, most of whom are not even coaches, but rather people that have mastered agile jargon and know how to impress HR and uninformed hiring managers → weak coaches (most of whom have minds of conformists, not challengers) cannot effectively guide companies to fix systemic weaknesses and dysfunctions → teams and departments don’t really improve; rather create a superficial appearance/illusion of progress (often, to impress senior management) → companies lose faith and stop seeing value in coaching → companies start trivializing a coaching role → companies decide not to spend more money on high quality coaching → cheaper, even less effective, coaches are hired (or internal, misplaced people are refurbished into coaches, overnight, as per Larman’s Law # 4) → initially, low-set coaching bar, is lowered even further…and so on….
Graphically, it looks something like this:
As a result, what was initially meant as a strategic organization- improvement effort, now takes on a form of just another system-gaming change management fad that ultimately leads to a failure and responsibility/blame-shifting.
What are some of the reasons why the above happens? Here are some suggested reasons:
- Companies don’t understand the essence of agile coaching role: it is viewed as another “turn-on switch” management function
- Leadership does not feel a sense of urgency (p. 14) to make changes and exempts itself from being coached: people are too busy and too senior to be coached; they find coaching trivial
- Certain organizational pockets are genuinely resistant to/feared of changes that can be brought about by real coaches (as per Larman’s Laws 1 – 3)
- Market over-saturation with unskilled recruiters that hunt for low-quality coaches and contribute to the above cycle: this further lowers a company’s chances to find a good coach
- This list can be extended….
Who is responsible for initiating this vicious cyclic dysfunction? Does it really matter if we identify guilty ones? Maybe it does, but only, as a lessons-learning exercise. What probably matters more is how to break out of this cycle. Where to start: discontinue low-quality supply (coaches) or raise a bar on demand (by companies)? Usually, demand drives supply and if so, for as long as companies remain complacent and reliant on outlived staffing/head-hunting approaches, cold-calling techniques, and ineffective HR-screening processes, performed by people that poorly understand the essence of an agile coaching profession, while trying to procure cheap “agile” resources or treat seasoned professional coaches, as “requisitions to be filled”, a coaching bar will remain low, and companies will be getting EXACTLY what they have paid for: coaches-centaurs.
“What should companies be looking for when hiring a coach?”
An organization should be looking much father and beyond of what is typically presented in a resume or a public profile of a candidate: usually, a chronological list of an employment history or a long list of google-able terms & definitions, popular jargon or claims of experience in resolving deep, systemic organizational challenges with Jira configurations 😊. Much more attention should be paid to the following important quantitative characteristics of a coach:
Coaching Focus: What is an approach and/or philosophy to coaching does a coach have? This will help a company understand an individual mindset of a coach.
Coaching Education AND Mentorship: What active journey through education, mentorship and collaborative learning in coaching and related activities over significant period has a coach taken?
Formal Coaching Education: What has contributed significantly to a person’s coaching journey, including courses on topics of facilitation, leadership, consulting, coaching, process, and other related activities which have influenced a person’s coaching practice? Such education may not have to be degree-related (training and/or certification from any recognized institution could be sufficient).
Coaching Mentorship & Collaboration: How a coach developed a skill/technique or received guidance to a coaching approach and mindset? Respect and recognition of mentors – matters here.
Informal Coaching Learning: What important topics outside of Agile/Scrum literature have impacted a person’s coaching philosophy? This increases chances that a coach is well-rounded, beyond standardized book learning.
Agile Community Engagement & Leadership: Does a coach engage in agile user groups, gatherings, retreats, camps, conferences, as well as writing, publishing, reviewing, presenting, facilitating, training, mentoring, organizing, and leading agile events? An active participation and leadership in the agile community is a good demonstration that a coach has not developed herself within a unique organizational silo, by self-proclaiming and self-promoting, but rather has diverse and ‘tested’ industry experience.
Agile Community Collaborative Mentoring & Advisory: Does a coach mentor or advise other individuals (not for pay) on how to increase their competency or development? Is a relationship on-going, purposeful and bi-directionally educational?
Coaching Tools, Techniques and Frameworks: Does a coach develop awareness and understanding of tools, techniques and frameworks while engaging with organizations? Has she customized or developed anything that was client/engagement-specific?
In addition to quantitative characteristics , here are qualitative characteristics of a good coach:
While running some risk of sounding self-serving (very much NOT! the intent here) : please, be mindful and responsible when you select guidance-level professionals in your agile journey 😉.
What is the best Sprint length? Who decides on Sprint length? Are there any exceptions? What are some of the most common mistakes people make, when making decisions about Sprint length?
Let’s start from grassroots and answer the following basic question: “What is Sprint main goal?” And while looking for an answer, let’s refer to the Scrum Guide, where the goal of each sprint is clearly described as “…increment (a.k.a. PSPI = potentially shippable product increment) that must be in usable condition and meeting DoD (Definition of Done)”. From the Scrum Guide perspective, it is also clear that while being potentially shippable, an increment does not necessarily have to be shipped. Why is it so? For PSPI to be shipped, it must also represent MMP (Minimal Marketable Product) and the decision about what is marketable comes only from Product Owner and it is based on several factors, including long-term strategy and economics.
(Note: End-of-Sprint deliverable, sometimes, is also referred to as MVP (Minimum Viable Product) and is described well by Roman Pichler here.)
Sprint Length and Release Economics
Speaking of economics, lets recall the relationship between Transaction Costs (Shipping) and Holding Costs, also described in “The Principles of Product Development Flow” by D. Reinertsen. By analogy, if applied to Scrum product development, ‘batch size’ would represent a volume of PSPI and ‘cost’ would represent all combined efforts, associated with production deployment (e.g. integration, end-user training, marketing announcements, etc.).
How does this relate to Sprint length?
While each Sprint is supposed to produce PSPI, it is only Product Owner’s decision ,when to release it (MMP), depends on finding a “sweet spot” between the two types of cost: Holding and Transaction, or if spoken, in software development terms, costs of code deprecation/aging and costs of deployment. On the graph above, it is illustrated by the lowest point of Total Cost curve and it is responsibility of Team and Product Owner to determine what it is.
Corollary to having both strategy and economics changing over time, release frequency may change as well. It would be natural to assume that sprint duration and release frequency are related too. Indeed, the need to release more frequently may lead to sprint shortening, and vice versa.
Are there any other external factors that may influence Sprint frequency of a single Scrum team? The most classic example would be Scrum by multiple teams that sprint together (e.g. LeSS, S@S): develop the same product, for the same Product Owner, and share the same a backlog. While release economics principles would still apply, the situation with scaling may become more complex if multiple teams are tasked to select a shared cadence. One assumption comes to mind immediately: if multiple teams sprint together (synchronously), then their shared PSPI (overall output) will be more substantial (“voluminous”) than that of a single team, and from a Product Owner’s point of view, may sooner merge the gap between PSPI/MVP and MMP (more about factors influencing Sprint length below).
In other situations, e.g. in non-scaled settings, individual Scrum teams could be dependent on other teams (Scrum, Kanban, Waterfall groups, etc), separate organizational domains or external vendors that operate on their own cadence. In such cases, product backlog refinement and sprint planning becomes even more challenging. As a result, sprint length, as well as frequency of scheduled production releases may be impacted.
Who Ultimately Decides on Sprint Length?
Just like any other decision about Scrum team dynamics, the decision on sprint length belongs to a team. Nobody should be deciding how to structure or manage work, on behalf of people that actually do it. Neither Product Owner, nor stakeholders, nor management, nor anyone else. Teams that are new to Scrum may experiment with sprint length at the beginning, while trying to optimize to conditions that are very specific to a team’s dynamics. The best time to self-assess and decide if sprint length should be changed is during a retrospective, when decisions about process improvements are made; and it is done by majority voting. Only in rare cases, when a team has a difficulty to reach consensus, ScrumMaster , who owns Scrum process and plays the role of an arbitrator in retrospectives, can step in and help a team make a choice. This should happen rarely, as frequent lack of consensus might be a sign of deeper team dysfunctions. Initially, during team formation, and before ScrumMaster is elected, Scrum/Agile coach may help team with sprint length selection. Mike Cohn describes his personal experience in a similar situation here.
Factors to be considered while selecting Sprint length?
As a rule of thumb, sprint length should not be shorter than 1 week and should not be longer than 4 weeks. If there is a strong reason to make sprints shorter than 1 week (e.g. could be driven by production release frequency requirements), Kanban, instead of Scrum, could be considered, since it offers, on demand and almost instant, release capabilities. On the other hand, extending sprint length beyond 4 weeks may lead typical challenges of waterfall (sequential work, silos, hand-overs).
Statistically, anywhere between 1 and 4 weeks, a team should be able to establish a steady and healthy cadence to do product development.
Shorter sprints do have certain advantages:
- More frequent sprint reviews and retrospectives – shorten feedback loops that allow applying improvements to product and process development, respectively.
- Shorter sprints require lighter sprint planning and, subsequently, reduce the risk of going too deep into a product backlog and selecting items for a sprint that do not meet DoR (Definition of Done) and are not INVEST-able.
Shorter Sprints may also bring some potential challenges:
- For example, the ratio of time spent on sprint preparation and process management to time spent on actual product development could be high – too much procedural overhead.
- Additional important prerequisites must be met, before moving teams to shorter sprints. For example, if a sprint becomes too short (e.g. 1-week) and there is no full test automation and no TDD, then a team may have a difficult time, keeping up with testing: after completing a few sprints, as the amount of code base increases, manual testing will fall behind. As a result too much work may fail DoD by Sprint-end.
Relationship between Sprint length and Scrum Maturity
It would be reckless to claim that there is a direct cause & effect relationship between sprint length and maturity. Some research indicates (some was done by Jeff Sutherland) that for as long as a sprint is under 1 month, there is no strong and immediate correlation between sprint length and performance. But anything beyond 4 weeks lowers performance and introduces elements of waterfall dysfunction to a team’s dynamics.
What is, by far, more important than sprint length is sprint length consistency. While in early stages of sprinting, it is normal for a team to experiment with sprint length, if length “juggling” continues into later sprints or happens ad-hoc, it could be viewed as a sign of deeper problems. Some teams falsely believe that by periodically extending a sprint they will be able to get more work to Done state. Thinking more systemically, this is a false assumption, as cadence- and task-switching, especially done by multiple teams, can significantly lower overall output. Further, inconsistent sprint length will lead to difficulty of sprint planning, unstable velocities and unreliable long-term forecasting.
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.