Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.
Experience Report of Guest-Blogger Ram Srinivasan
Experience Report of Guest-Blogger Mark Uijen de Kleijn
LeSS Graphic Art
Personal Memorable Moments
Next LeSS conference (2019) – Munich, Germany
- Wrote Extreme Programming Installed (also with Ann Anderson)
In 2009, developed for Scrum Alliance the Certified Scrum Developer program
- Taught the first Certified Scrum Developer (CSD) course
- Have been curating the Scrum Alliance’s Agile Atlas website
- Created the SA’s official Scrum description, Core Scrum
- Speak at conferences, bringing an interesting mix of humor and deep knowledge, and the odd cat picture.
This is what Chet had to say about the course:
“Chet Went to Craig’s LeSS Course”
Many years ago, I wrote an article entitled “Inside every 100-person project is a 10-person project trying to get out.” That pretty much sums up my feelings about Agile at scale.
Craig’s organizing principle for the course is that in order to successfully use these ideas, you must own them. Having an instructor, no matter how good they are, no matter the depth of their experience, teach you something is no where as good as discovering the answers yourself. To this end, we spent most the the course learning and practicing organizational modeling to derive the practices and structures that align with our goals.
Some more Kodak moments from the event are below:
The purpose of this post is to summarize two very important and independent topics and then integrate them together, into a joint discussion. The topics are:
- Moving from rigid annual budgets to rolling forecasts (super important! in agile/adaptive product development environments)
- Quality of scaling in agile product development, specifically Scrum
…and tying effective scaling of Scrum to dynamic financial forecasting.
Rigid Annual Budgets vs. Dynamic/Rolling-Wave Forecasting
Challenges presented by rigid annual budgets have been known for a long time. For people that are new to the topic, a great way to stay on top of most recent research and publications, is to follow what is going at BBRT.org (Beyond Budgeting Round Table). One of BBRT’s core team members – Bjarte Bogsnes, in his book “Implementing Beyond Budgeting: Unlocking the Performance Potential” (please, refer to the book’s highlights here), clearly summarizes the problems with conventional, end-of-year rigid budgets. They are as follows:
- Budgets represent a retrospective look at past situation and conditions that may not be applicable in a future
- Assumptions made as a part of a budgeting process, even if somewhere accurate at the beginning, get quickly outdated
- Budgeting, in general, is very time-consuming process, and it adds additional, financial overhead to organizations
- Rigid budgets, can prevent important, value adding-activities, and often lead to fear of experimenting, researching and innovating (crucial for incremental development)
- Budget reports are frequently based on subjective metrics, as they take on the form of RAG statuses, with the latter, introducing additional errors and omissions (for details, please refer to Red, Yellow, Green or RYG/RAG Reports: How They Hide the Truth, by M. Levison and The Fallacy of Red, Amber, Green Reporting, by G. Gendel)
- Budgets, when used as a yardstick to assess individual performance, often lead to unethical behaviors (e.g. “churning & burning cash”at year-end to get as much or more next year) or other system-gaming activities
…The list of adverse effects caused by traditional budgeting is long…
On contrary, a rolling-wave forecast, respects the fact that environmental conditions are almost never static, and recognizes that if too much reliance is placed on prior years’ financial situation, it may lead to miscalculations. Rolling-wave forecasts are based on frequent reassessment of a small handful of strong KPIs, as oppose to large number of weak KPIs, as frequently done in conventional budgeting.. The more frequently forecasts are being made, the higher chance that most relevant/reliable information will be used in assessments. One good way to decide on cadence of rolling forecasts is to align them with meaningful business-driven events (e.g. merchandise shipments, production code deployments, etc.). It is natural to assume that for incremental/iterative product development (e.g. Scrum), when production deployments are made frequently and in small batches, rolling-wave forecasting could be a concurrent financial process. Short cycle time of market feedback could provide good guidance to future funding decisions.
It is worth noting that one of the key challenges that Scrum teams face today, is the “iron triangle” of conventional project management, with all three of its corners (time, scope, budget) being rigidly locked. And while the most common approach in Scrum is to make scope flexible, ‘clipping’ the budget corner brings additional advantage to teams. Above all other benefits, rolling-wave forecasts address the problem described in #4 above, as they provide safety to those teams that want to innovate and experiment.
But what if there not one but many Scrum teams, each working on their own initiatives, running under different cadences (asynchronized sprints) and servicing different customers? How many independent rolling-wave forecasts can one organization or department adopt before things become too complicated? What is too much and where to draw a line?
Before we try to answer this question, let’s review what is frequently seen, when organizations attempt to scale scrum.
Proper Scaling vs. “Copy-Paste” Scaling
Let’s look at the following two situations: (1) more than one Scrum team, independently, doing their own Scrum and (2) more than one Scrum team, working synchronously, on the same product, for the same customer, sharing the same product backlog and domain knowledge. The former case, is referred to as “Copy-Paste” Scrum, clearly described by Cesario Ramos. The latter case can be seen in skillful Large Scale Scrum (LeSS) adoptions. Here are some of the most classic characteristics of both scaling approaches:
|(1) – “Copy-Paste” Scrum||(2) – Large Scale Scrum (LeSS)|
Note: Please refer to Scaling Organizational Adaptiveness (a.k.a. “Agility”) with Large Scale Scrum (LeSS) for additional graphic illustration.
Based on the above, the following also becomes apparent:
In “copy-paste” Scrum, development efforts, marketing strategies and sales (ROI) are not treated as constituents of the same unified ecosystem. In this scenario, it is almost impossible to fund teams by means of funding real, customer-centric products. Why? There are too many independent ad-hoc activities that take place and artifacts that are created. There is no uniformed understanding of work size and complexity that is shared by all teams. Estimation and forecasting made by each individual team is not understood by other teams. Team stability (and subsequently, cost-per-team member) is low, as individuals are moved around from project to project and shared across many projects. Further, with multiple teams reporting into different lines of management, there is a much higher chance of internal competition for budget. By the same token, there is a low chance that a real paying customer would be able to step in and influence funding decisions for any given team: too many independent and competing requests are going on at the same time.
In organizations, where “copy-paste” Scrum is seen (and is often, mistakenly taken for scaled scrum, due to lack of education and expert-leadership), there is still strong preference for fake programs and fake portfolio management. Under such conditions, unrelated activities and, subsequently, data/metrics (often fudged and RAG-ed) are collected from all over the organization and “stapled” together. All this information rolls up to senior leadership, customers and sponsors. Subsequently, what rolls down, is not dynamic funding of well-defined customer-centric, revenue-generating products, but rather rigid budgets for large portfolios and programs that are composed of loosely coupled working initiatives, performed by unrelated Scrum teams (secondary, to conventional departmental budgeting). As rigid budgets cascade down from top, onto individual teams, they further solidify the “iron triangle” of conventional project management and hinder teams’ ability to do research, experimentation and adaptive planning.
On the other hand, in Large Scale Scrum, things are different:
- When up-to-eight LeSS teams work synchronously, together (side-by-side), on the same widely-defined product (real), their shared understanding of work type and complexity (having certain scrum events together really helps!) is significantly better. As a result, when it comes to forecasting a completion of certain work (features), eight LeSS teams will do a better job than eight loosely coupled teams that work completely independently, on unrelated initiatives.
- Since all LeSS teams work for the same customer (Product Owner), there is a much higher chance that they will develop a shared understanding of product vision and strategy, since they are getting it from an authentic source – and therefore will be able to do planning more effectively.
- Having more direct correlation between development efforts LeSS teams (output, in the form of shared PSPI) and business impact (outcome, in the form of overall ROI), makes strategic decisions about funding much more thoughtful. When real customers can directly sponsor product-centric development efforts, by getting real-time feedback from a market place and deciding on future strategy, they (customers) become much more interested in dynamic forecasting, as it allows them to invest into what makes most sense. Dynamic forecasting of LeSS, allows to increase/decrease number of scrum teams involved in product development flexibly, by responding to increased/decreased market demands and/or product expansion/contraction.
Noteworthy that in LeSS Huge cases, when product breadth has outgrown capacity of a single Product Owner and requires work by more than eight teams, dynamic forecasting can still be a great approach for Product (overall) Owner and Area Product owners (APO): they can strategize funding of different product areas and make necessary timely adjustments to each area size/grown, as market conditions change.
All of the above, as described in LeSS scenario, will decrease organizational dependency on fixed budgets, as there will be less interest in outdated financial information, in favor of flexibility, provided by rolling-wave forecasting that brings much closer together “the concept” (where value is built – teams) and “cash” (where, value is consumed – customers).
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:
Nowadays, for too many organizations, Agile Maturity Metrics (AMM) have become a trusted way to measure improvements of agility at personal (individuals), team and organizational level.
However, it is not always apparent to everyone that AMMs are different from Agile Check-Lists (e.g. classic example of Scrum Check list by H. Kniberg) and this can often lead to problems and dysfunctions:
Check-Lists are just a set of attributes that are usually viewed on-par with one another; they are not bucketed into states of maturity (other logical grouping could be applied though)
On contrary, AMMs place attributes in buckets that represent different states of maturity, with one state, following another, sequentially.
With very rare exceptions (favorably designed organizational ecosystems), there are three potential challenges that companies face, when relying on bucketed AMMs:
1 – System Gaming: If achieving a higher degree of agile maturity is coupled with monetary incentives/perks or other political gains (for many companies that are driven by scorecards and metrics, this is the case), there is will be always attempts by individuals/teams to claim successes/achievements by ‘playing the system’, in pursuit of recognition and a prize.
Note: Translation of the text in red: “(Пере)выполним годовой план за три квартала!!!” = “Will meet/exceed the annual plan in three quarters!!!”
2 – Attribute-to-Maturity Level relationship is conditional, at most: Placing agile attributes in maturity buckets implies that attributes in higher-maturity buckets have more weight than attributes in lower-maturity buckets. However, this is not always a fair assumption: weight/importance that every organization/team places on any given attribute, while defining its own maturity, is unique to that organization/team. For example, for one team, “…being fully co-located and cross-functional…” could be much more important than “…having Product Owner collocated with a team…” For another team, it could be the other way around.
3 – Correlation between attributes is not linear, at system-level: Regardless of buckets they are placed in, many agile attributes are interrelated systemically and impact one another in ways that is not apparent, to a naked eye. For example, placing “Scrum Master is effective in resolving impediments”attribute in a maturity bucket that comes before the maturity bucket with “…Organization provides strong support, recognition and career path to Scrum Master role…” attribute, dismisses the real cause-and-effect relationship between these two variables, misleads and sets false expectations.
To avoid the issues described above, it would be more advisable to treat every identified agile attribute as a system variable, that is on-par with other system variables, while assuming that it has upstream and downstream relationship. In many situations, instead of spending a lot time and resources on trying to improve a downstream variable (e.g. trying to understand why it is so difficult to prioritize a backlog) it is more practical to fix an upstream variable that has much deeper systemic roots (e.g. finding an empowered and engaged product owner who has as the right to set priorities).
Below, is the list of agile attributes (a.k.a. system variables) that are logically grouped (check-list) but are not pre-assigned to levels of maturity (all flat). Some examples of suggested system-level correlation between different attributes are provided (cells are pre-populated).
Please, click on the image to download the matrix to your desktop, amend the list of attributes if you feel that your situation calls for modification, and then use “Dependency on Other Attributes?” column to better visualize system-level correlation between the attributes are of interest to you and other related attributes (some examples are provided).
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:
[also, cross-posted on less. works]
Large Scale Scrum (LeSS). It is the framework for scaling agile development, done by multiple teams, as they work on same product and work for a single Product Owner. In order to be effective, LeSS requires organizational descaling that means simplification/flattening of organizational design.
What is Organizational Design? To understand it better, let’s look for analogy in construction industry. What is required to erect a building? In our analogy, we shall stay simple: bricks (foundation block) and cement (connective material that holds bricks together).
Imagine two buildings: Building A and Building B.
Building A uses brick as its main foundation block. In fact, when looking at the building’s facade, the most prevalent object, caught by a naked eye, is a brick. Bricks are positioned next to one another, with just enough cement in-between to glue them strongly together. There is no excess of cement anywhere: the connection layer is very thin/lean.
Architectural design of building A is simple and flexible: the structure is flat (one-story high) and it sits on strong foundation, also made of brick. Because of its design, architectural adjustments are possible in various sections of the building, independently, with little additional labor. Due to such modular structure, the building can be expanded laterally, just by adding more bricks to the wall. Of course, due to its flat structure, the building is also very stable and can withstand a strong wind, flood or an earthquake: practically nothing can be shaken off or washed off the building.
When waste is produced inside the building, it becomes noticeable immediately. Waste disposal is also very simple: it does not require complex chutes or automated waste ‘packaging’ systems. Waste removal can be mostly done manually, by building residents. Any necessary supplies (e.g. food, water, furniture, other materials) can be easily delivered to any building area, without the need of advanced technology or mechanics.
Finally, building inspection and maintenance is a very easy process, because of flat structural design: foundation, walls and floor assessment – all can be performed with a naked eye; corrections can be done timely and efficiently.
This is what building A looks like:
Building B is made of a very few bricks and a lot of cement in-between that holds bricks together. In fact, the ratio (by weight) of bricks-to-cement is very low.
Architectural design of building B is rigid. It has many floors, with top floors made primarily of cement. The building represents a heavy and monolithic structure, and although it also sits on brick foundation, as building A, the bricks are widely spaced with lots of cement in-between. This means that the overall weight of building B is dangerously high (foundation can crack). The building’s expansion limit, to accommodate growing occupancy demands, is low: it cannot be easily extended (scaled) horizontally with a couple of extra bricks added to the side, because the bottom brick layer would require multiple horizontal cement layers added on top – to follow the originally intended building design. If additional cement layers are added on the top of foundational brick layer this will further increase risks of foundation cracking.
Waste disposal is a serious issue for Building B. While waste can be relatively easy removed from the bottom floor (it is also not in abundance there) and, to some extent, from top floors (by taking it to the roof and using a waste removal chopper 😊), there is a huge amount of waste that gets accumulated at middle floors – and it sits there. It is extremely challenging to remove this mid-section waste and what building management does from time to time, is ordering for this waste to be moved from one floor area to another (the building is very compartmentalized). Sometimes, waste gets moved to floors above; sometimes – below. This creates an illusion of waste removal. But waste remains.
Delivery of supplies and food to Building B occupants is a real challenge, especially if elevators are out of order. This makes occupants angry and frustrated and sometimes they turn onto each other; become competitors and rivals.
Finally, building inspection and maintenance is a nightmare for Building B. Many living units are out of compliance with building codes, but violations (and violators) are hard to identify and remove because true facts are well concealed and numbers are gamed by building occupants.
This is what building B looks like:
Large Scale Scrum requires organizational design that is analogous to the construction represented by Building A.
Team represents the main building block (a brick). Selected team representatives (developers) and mentors-travelers–ensure effective coordination/connection between teams. There are no additional roles required for coordination. Cross-team events are minimal (Overall Product Backlog Refinement, Sprint Review, Overall Retrospective).
If product definition widens and more developers are included, another team can be formed and positioned laterally to existing teams – just like a brick. Should product definition become too wide and the number of required developers exceeds 50-60 people (8 teams), another product area can be identified (new independent module, made of bricks). Now, LeSS becomes LeSS Huge. The only additional coordination that would be required in LeSS Huge is between Area Product owners and Overall Product owner – for strategic planning of Potentially Shippable Product Increment (PSPI) at the end of every sprint. In both, LeSS expansion from 2 to 8 teams, and LeSS Huge expansion beyond 8 teams, there is no need for additional coordination that is different from what is described above (no extra cement needed to keep bricks together). Also, in LeSS Huge, when one Product Area expands and another one shrinks, moving the whole team from one area to another, does not require expansion or shrinkage of any additional “supportive” organizational layers.
By design, LeSS foundational structure is very lean: flat, fungible and cross-functional. There is no waste or overhead with roles, responsibilities, events or artifacts. Everything is very minimalistic. If any waste is generated in LeSS, it has practically nowhere to hide.
Because there is so much transparency in LeSS, waste is seen immediately. Any findings of waste or any other required improvements to individual teams or LeSS framework, can be effectively done in Team Retrospective or Overall Retrospective, respectively. Thanks to its flat organizational structure, LeSS (and LeSS Huge) don’t have to worry about waste removal from additional organizational layers – they [layers] just don’t exist. There are fewer layers that sit between LeSS teams and LeSS Product Owners and these layers are much thinner.
What happens with LeSS organizational structure during rough times: slow down in business, increased market competition? Arguably, because LeSS is so lean and there is continuous learning, it is much less likely that LeSS people will be displaced. LeSS is also more likely to withstand other types of reorgs and shake-ups because LeSS has very few moving parts, loose pieces or weak links.
Organizational designers that support LeSS think like building architects that want to build strong, reliable, easily-maintainable, low-waste, cost-effective and long-lasting structures!!!
Many thanks to all LeSS Trainers, Coaches and Practitioners building reliable structures 😉.
Signed: ____________The Organizational Building Management 😉
2017 Scrum Coaching Retreat in Kiev is in the books!!! The event has brought together a few dozens of agile coaches and trainers from nearby and far away.
The participants came from different backgrounds and focus areas but due to everyone’s extensive experience in self-organization and self-management, got the show on the road very quickly. After a short round of self-intros, each participant introduced a few topics that they wanted to discuss. By using a combination of dot-voting and affinity clustering techniques, the group came up with a handful of key topics that everyone wanted to deep dive into. The group broke up into four teams, with each team picking one high-priority topic – to be worked on in consecutive three (3) sprints.
The team I joined (“Happy 7”) picked up the topic “How to influence decisions of senior management directly, from the bottom of organizational pyramid”. The team consisted of experienced ScrumMasters, Team-level and Enterprise-level coaches.
The problem statement that defined our team’s effort was:
“There are so many instances, of challenges and obstacles that teams face, are not being heard at the top of a food chain. And even when they are heard, often, original messages get distorted and lose urgency, as they travel up through multiple “translational” layers. What can be done to fix this problem? What techniques could be used to effectively segregate impediments that are local and can be resolved by teams and the ones that are systemic/organizational – and must be aggressively escalated upward?”
The problem above has direct dependency on organizational design, specifically, on its thickness: the number of organizational layers between working teams (on one hand) and senior leadership/paying customers (on the other) – is a well-recognized challenge today.
Our working group has identified the following organizational design scenarios that define dynamics and human interaction in modern Product Development:
- Development teams and Product Owner belong to the same organization and end-Customer is positioned internally
- Development teams and Product Owner belong to the same organization and end-Customer is positioned externally
- Development teams represent Vendor-company and Product Owner represents Client-company and relationships between Vendor and Client are based on:
- Out-staffing model – when a vendor provides human assets (developers) that are then owned by a customer, from management perspective, whereas legal ownership (e.g. insurance, taxes) is still by a vendor
- Out-sourcing model – when an entire project gets outsourced to a vendor and a paying customer has no or minimal interaction directly with human assets (developers) that do work (most of communication flows through Engagement Management)
Interestingly, since many of our working group members had a lot of experience with #3 option above, the primary focus of our discussion was about how to bring closer senior leadership of paying customers and agile teams of delivering vendors, closer together, despite multiple “anti-agile” organizational layers that frequently reside in-between the former and the latter.
The ultimate result of our brainstorming was the invention of a non-commercial, collaborative game that was given the name of Influence Poker.
Our game’s purpose was:
- To identify challenges that delivery teams often face
- To classify challenges, based on origin, severity and implications
- To discuss potential ways of resolving and/or escalating challenges
- To ensure resolution ownership and transparency on its progress
The most serious organizational design challenge, when a paying customer engages with a vendor-company, is seen with an out-sourcing model. Here, no matter how agile/robust technology teams are, their ability to deliver effectively is hindered by:
- Involvement of Delivery Manager (usually, placed on a client site) who owns a relationship with a customer, serves as a single filter-channel of communication between a customer and teams, makes commitments and furnishes progress reporting on behalf of teams. The same person also streamlines feedback from a customer back to teams and frequently assigns work to team members. This is usually accompanied by micro-management and command and control behavior. The situation can be further worsened by the presence of Vendor Management function (customer side) that enforces SLAs, SOWs and other formal contracts between a customer and vendor: this just adds additional tension to a relationship and moves further apart end-customers and delivery teams.
- Weakening of Product Owner role – the importance of this critical Scrum role gets downplayed, because a customer company no longer sees value in direct communication with technology teams. Instead, Delivery Manager is treated as a single person, responsible for project delivery. This dramatically narrows all communication media that are used in Scrum (holding events, sharing artifacts).
The above two challenges are inter-related through a positive feedback loop: the less disengaged Product Owner becomes, the more pivotal the role of Delivery Manager becomes. The opposite is true too: strengthening the role of Delivery Manager, leads to further “excusing” Product Owner from stepping into the game, as Scrum requires. This is a viscous, de-stabilizing loop that continuously weakens Scrum.
Please, look out for the Influence Poker.first official release that is coming soon! It may greatly help your teams visualize their organizational problems and discover potential workable solutions.