Category Archives: LeSS

LeSS Adoption Preparation References




 

LeSS Talks: May 22: Darwin Theory of Agile Coaching Evolution, with Ron Whitebread



Learn how one company iterated on their coaching approach – from experimentation to big consulting “transformation” to systems thinking enablement (transitioning from being supported by one of Big 5 consultancy companies, with their “push agile” model,  to a reputable, boutique agile coaching and training company) – to become more effective in achieving desired outcomes, what pain points each approach was trying to address, and how to become more relevant to the business side of Agility.

Understand how three different ecosystems played into how our focus and approach kept evolving to fit the prevailing context of that period – the environment, goals, pros/cons and reflection on those outcomes for each approach used.

Ask About LeSS Training & Coaching

04/11 – LeSS Talks: Branching Strategy and CI/CD in Agile Development, with Thierry de Pauw




Materials | Speaker’s Site

Main Take-away Points:
  • “Developing in isolation can help an individual go faster but it does not help a team go faster. Merge time and rework cannot be estimated and will vary wildly, and the team can only go as fast as the slowest merge.” – Steve Smith
  • “A spike solution is a very simple program to explore potential solutions. Build the spike to only address the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away.” – Don Wells
  • “The objective is to eliminate unfit release candidates as early in the process as we can …You are effectively prevented from releasing into production builds that are not thoroughly tested and found to be fit for their intended purpose.” – Jez Humble and Dave Farley
  • “Feature Branching is a poor man’s modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploy-time they couple themselves to the source control providing this mechanism through manual merging.” – Dan Bodart
  • “Feature Branching hinders integration of features.”
    “Feature Branching hides work for the rest of the team. Frequently merging back to mainline = communicating with your team”
  • “Feature Branching works against refactoring.”
  • “Feature Branching creates inventory.”
  • “Feature Branching increases risk.”
  • “Feature Branching creates cognitive overload.”
  • “Continuous Integration Your application is always in a releasable state on main line – with Trunk Based Development”
  • “Continuous Integration Your application is always in a releasable state on main line.”
  • “Break large changes into a set of small incremental changes”
  • “Use Branch by Abstraction when performing large refactoring.”
    “Feature Toggles to decouple feature release from code deployment.”
  • “Trunk-based development requires a big mindset shift. Engineers thought trunk-based development would never work, but once they started, they could not imagine ever going back.” – Gary Gruver

Additional Learning Assets:

02/27 – LeSS Talks: Facilitating LeSS events virtually (using Miro, Mural)




Facilitating LeSS events virtually (Ideas, Tips & Tricks)

Tools and platforms shared in the session:

Additional Self-Study Assets:

LeSS vs. SAFe: Understanding The Differences


History & Origins

SAFe was created by Dean Leffingwell – a successful entrepreneur and software development methodologist who has consulted to many companies, over years, including Rational Software, Rally Software, as well as many others.  Dean’s LinkedIn profile displays “Chief Methodologist” in the title.  LeSS was co-found by Craig Larman and Bas Vodde – both of whom are hands-on software developers, with many years (up until today) of experience, in large-scale, multi-site product development environments, including product companies, large telecom and investment banking.  Both co-founders have a lot of experience with organizational design and system modelling (a big part of LeSS).  Interestingly, Craig’s LinkedIn profile states “public safety, junior programmer” and Bas’s – “team member“.  The irony is in the modesty of their titles, since both co-founders have made a monumental investment in the industry, in the area of agile product development during the last few decades.

The initial release of SAFe program was in 2011, with five major release that followed.

Although, as an *official* framework, LeSS was announced only in 2015, its history goes back decades. The three Large Scale Scrum product development books were written in 2008, 2010 and 2016 years, respectively, with many field experiments collected over of the years, prior to 2008.  Essentially, LeSS has been a huge body of knowledge, collected over many years, before it became known as the framework.

 

Market Share, Framework Versioning and Certifications

SAFe is very widely known.  Its market share in the world of scaling is by far, the highest of all known frameworks.  Consultancy market is dominated by Certified SAFe Product Consultants (SPC) that hold, at least one, of many SAFe badges.  Because there are so many versions of SAFe (2.0, 4.0, 4.5, 4.6, 5.0), naturally, certification holders are driven to come back, for an upgrade training, to remain ‘up-to-date’.  Since SAFe supports a number roles that are aligned to traditional organizational roles, many SAFe courses are role-specific.  The number of instructors that can deliver SAFe courses is also high, with many course-reselling companies being actively involved in marketing, promotion and re-selling.

LeSS is not as widely known. Its market share, relatively to SAFe, is low.   There are only three main types of LeSS certifications (Basics, Practitioner and Executives),  with other few types, mainly, being on-line versions of the main ones.   LeSS training/certification is not ‘role-specific’.  LeSS adoptions are deep and narrow (as oppose to being broad & shallow).  According to field experts, there is no expectation that LeSS will become a mainstream in a foreseeable future.  This is because LeSS has high expectations for organizational design improvements (see below) that many companies are not yet ready for.  Today, there are very few LeSS trained/certified people because the number of accredited LeSS instructors is also relatively low (slightly over 20 people, globally).  LeSS, just like Scrum, does not have any versions.  There are two LeSS frameworks: [simple] LeSS framework (up to 8 teams) and LeSS Huge (stacks of LeSS, totaling hundreds or more people, if required).

 

Influence by Large Consultancies

Many large consultancies recommend SAFe to its clients, as a framework of choice (Note: As a corollary, many companies-clients, to officially remain framework-agnostic, adopt their own flavor of SAFe, essentially, using their own internal terminology, while mimicking/mapping to SAFe terminology, structure, etc).  For large consultancies, this ensures a more profitable and prolonged engagement, since SAFe implementation involves many people, processes and tools (see below).  Dave Snowden refers this type of engagement as an ‘industrial model’, since it ensures a “massive roll out, with lots of people, over a long period of time” (also, see this “Triple Taxation” illustration to understand a financial impact on companies-clients).  Another reason why SAFe happens to be a framework of choice by large consulting companies, is that the framework itself does not require any major changes to a traditional organization design and as such, does not put large consultancy representatives, in an uncomfortable position of purists-radicals that have to challenge their clients’ ways of working (not too much status quo challenging ensures a longer and more profitable engagement).

LeSS does not have much recognition by large consultancies for the following three suspected reasons: (1) organizational design of large consultancies [themselves] is inconsistent with LeSS teaching and therefore, there are no internal success stories to share with clients; 2) consultants don’t have enough LeSS adoption knowledge to comfortably support their clients with LeSS adoptions; 3) risk aversion, as stated above (fear to challenge radically, and therefore lose business), makes LeSS a bad choice.

 

Business Partnership with Tooling Companies

Today, almost any workflow management or bug tracking tool (e.g. VersionOne, Rally, VSTS/TFS, Jira, etc) is very closely aligned (some, also are strategically partnered) with SAFe.  This makes SAFe adoption especially convenient, since practically any large company today has one (sometimes, multiple) of the above mentioned tools in its arsenal, and considers them as a big part of agile transformation journey.   Practically, every tool that has the word *agile* in its name, also has a module/layer(s) that could be easily mapped (configured) to a multi-layered structure of SAFe.  This gives a sense of comfort to a company, about its own ‘agility fitness’, since now a company can conveniently fit its workload and organizational structure into a tool and framework.  This also creates great opportunities for SAFe and tooling companies to cross-sell and cross-promote each other.

LeSS is completely silent on what tools should be used to visualize work.  There are no strategic partnerships with tooling companies.  The only recommendation LeSS gives that whatever tooling is used, it should be very flat (simple) and easy to operate (e.g. no more than three levels of work decomposition; no commingling product and spring backlogs, etc).

 

Framework ‘Size’ and Traditional Organizational Design

SAFe involves many people, teams and departments.  One of the main reasons why so many organizations are comfortable to adopt SAFe is that it does not really challenge, a status quo of first-, mid-level management and traditional organizational design.  In one of his early-days webinars, recorded with VersionOne, Dean Leffingwell clearly stated: “…We don’t typically mess with your organizational structure because that is a pretty big deal…”. In SAFe, many traditional organizational layers (programs, portfolios) and roles (solutions architects, enterprise architects, various types of managers (project, program, portfolio, release, solutions, etc) have a place to exist.  SAFe provides a very safe environment for traditional managers: everyone has a role and some responsibilities. Notably, on a SAFe diagram, agile teams illustrated at the very the bottom of SAFe overall picture, with many management layers coming over the top.

LeSS product group consists of 2-8 teams (maximum 70 developers, assuming a maximum recommended number of developers in Scrum is nine), with a minimal number of additional roles involved (Product Owner, Scrum Masters, users, stakeholders).  LeSS Huge adoptions, with hundreds to thousands of people involved (they are gradual and take years) have a very minimal add-on to organizational complexity, in the form of [product] Requirement Areas, prioritized by Area Product Owners.

LeSS explicitly challenges traditional organizational design and calls for organization DE-scaling (flattening), as means of scaling agility and Scrum. In LeSS, a Team of developers is the key organizational building block.  In LeSS, middle and first-line managers are not requiredManagers in LeSS, if remain, radically change their focus from individuals and work-assignment management to capability-building and teams’ enablement.  In LeSS, programs and portfolios cease to exist.  LeSS is Scrum, applied to many teams, working together on one large product, and therefore, LeSS is best to use for product centric development, where a product centricity is really important (note: in LeSS a product could be a combination of software and hardware).

 

Team Structure and Coordination

SAFe includes various types of teams: agile teams, Kanban teams, XP teams and System teams, DevOps teams, architecture teams, etc.  In practice, these are single-functional specialty teams and component teams that are inherited from traditional organizational design and, therefore, still require a lot of additional coordination, integration of work and dependency management.  As such, there is a need for release managers (e.g. Release Train Engineers), Solutions Architects and other types of coordination managers – people that are responsible for bringing everything together.

In LeSS, all coordination between teams (each team is a cross-functional feature team) is done by teams, themselves (not even Scrum Masters).  Each team in LeSS is fully capable to deliver a product-centric backlog item (feature), from start to finish. In LeSS, teams are responsible for coordination and integration.  Dependencies in LeSS are viewed, as something highly undesirable (hard, asynchronous dependencies are viewed as a sign of organizational weakness), internal contracts (“us vs. you”) and unwillingness to work closely together – something that must be minimized, in favor of close collaboration among teams. In LeSS, a lot of emphasis is made on communication through code, mentorship, community learning and other lateral (horizontal) knowledge-sharing techniques.

 

Backlogs and Product Centricity

In SAFe, there are many different types of backlogs: team (private) backlogs, program backlogs, solution backlogs, portfolio backlogs etc. – each representing a respective organizational structure (people that are compartmentalized/departmentalized in their reporting verticals, ways of working and communication) and aligned with a specific team type, at various layers of the framework (e.g. , essential, program, solution, portfolio).  In order to keep all backlogs in sync and relevant, there is a lot of coordination and management required.

In LeSS, there is only one backlog: Product Backlog – shared by all (2-8) teams that work on the same, product, while servicing the same Product Owner.  As stated above, there are no programs or portfolios in LeSS – these traditional layers of WBS management are discontinued, in favor of a widened product definition.  There is a lot of direct coordination between teams in LeSS (intra- and cross-teams), by team members.

 

Product Ownership

SAFe Product Owner is a team member, who is responsible for defining/detailing and prioritizing team backlog items (frequently, component items).  SAFe PO can support, at most, 1 to 2 teams because focusing too much on details and tactical implementation requires a lot of time.  In practice, SAFe PO is often an ex-business analyst, ex-project manager or a tech-lead – something that works well, because majority of teams in SAFe are [technical] component teams.

LeSS Product Owner is conceptually the same as in one-team Scrum. However, in LeSS, PO focuses on an overall strategy and ensures maximum return on investment (ROI) in the product.  LeSS PO puts all of his/her focus on prioritization, whereas clarification, as much as possible, flows through users/stakeholders (see below).  In practice, LeSS PO is usually a product manager or a head of business operations (e.g. head of marketing, sales) – for external product development OR an experienced, hands-on individual from one of the major user departments, who is interested in taking on the role and is political savvy – for internal product development.

 

Proximity of Customers, Users and Stakeholders

In SAFe, it is less likely that business people will interact directly with developers, because there are specific, dedicated roles for such interaction. For example, Epic Owners (Portfolio level business people) interact directly with ART (Agile Release Team) / RTE (Release Train Engineers) and Solution Train / STE (Solution Train Engineers). Similarly, Business Owners (Essential SAFe level) that are responsible for governance and compliance, also interact with ART.

In LeSS, users and stakeholders are brought in direct contact with teams, and this is clearly defined in LeSS organizational design and rules of engagement, defined during initial (preparatory) phase of LeSS adoption (up to 2 months, prior to sprinting).  For the most part, all clarifications and details about product backlog items flow to teams directly from users and stakeholders.  In LeSS, there are no individuals or teams that are responsible for architecture only, solutions only or releases only – all these responsibilities reside within teams of LeSS Product Group, where all teams work on features, in a customer centric way.

 

Integration and Release Management

In SAFe, the System Team is responsible for development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. It is also responsible for integration of code, produced by delivery (agile) teams.  ART (Agile Release Team), spearheaded by RTE (Release Train Engineer) – responsible for releases.

In LeSS, teams (2-8 teams in LeSS Product Group) share the same Definition of Done (DoD) and are responsible for their own integration and production deployment.  Teams make take turns, from sprint to sprint, in leading these activities, while closely coordinating with other teams and cross-pollinating each other with knowledge on how to do it successfully.  There are no full-time dedicated teams to handle these special activities only.  If there is any work that teams are not able to complete by Sprint-end, it is qualified as ‘Undone’ department work (highly undesirable) and is considered as an organizational impediment.

 

Agile Leadership and Frameworks

Usually, SAFe is the framework of choice, when an organization is not ready to make any major significant changes and where the following organizational facets are considered “untouchable”: a status quo of mid-level management, traditional budgeting, traditional portfolio structures (projects, programs), traditional HR norms and policies.  SAFe adoptions are typically spearheaded by traditional groups, such as PMO, CDO or a center of excellence. People that are in charge of action are best described by Larman’s Law or Organizational Behavior # 4 – individuals that have fast-tracked themselves into agile experts.  Adoption of SAFe is a very effective way to provide role safety to many traditional roles, that by minor updates to their titles will remain involved with the effort.

LeSS adoptions have chance to succeed in environments, where there is a real urgency to change, and where there is a strong need to bring real, tangible business value to real customers and users soon.  Usually, people that drive successful LeSS adoptions come from hands-on product development (technology) or from business operations (e.g. sales, marketing).  The should be also supported by by seasoned organizational design consultants, with years of experience of serving multiple organizations.  Prior to proceeding with LeSS, senior management needs to be educated on organizational design implications of LeSS and it must provide an informed consent (explicit agreement to provide support in action, not just in-spirit).

 

Conclusion

All models are wrong, but some are useful“. – George Fox.

It is probably impractical to debate which framework is best to use.  In order to decide on the best choice, we need to understand what strategic goals and objectives an organization wants to achieve:

SAFe can provide a top-down mandatory structure and control over an existing organizational disarray, without challenging significantly traditional roles, responsibilities, hierarchies (reporting and WBS) processes and tools. Most likely, organizational complexity, will not be simplified with SAFe, but it might be worth it if benefits of order out-weight expected complexity.   If an organization wants to do a major, large-scale roll out, involving thousands of people at once, and prefers a well-structured, change management process, based on play books, templates, prescriptive execution and compliance, then SAFe could be  a good  choice.

LeSS, just like Scrum, is based on empirical process control and continuous inspection, adaptation and experimentation.  If LeSS is adopted, with its minimal rules and guidelines, it can provide an array of deep systemic improvements but not every company might be ready to accept them.  LeSS would also require a significant change to a sphere of control by traditional roles, responsibilities, hierarchies, processes and tools (LeSS adoption principle #1).  LeSS will challenge a status quo of some people, and therefore, success of LeSS adoption is strongly dependent on support by senior management (LeSS adoption principle #2) that must ensure job safety and career opportunities for impacted people.  LeSS adoptions will not be fruitful if they are mandatory and based on compliance.  Instead, LeSS adoptions require a genuine commitment and are based on volunteering (LeSS adoption principle #3).  For example,  the oldest, biggest and most active global LeSS (NYC) Meetup is based on the principle of volunettering.  One of the most powerful tools (also an effective coaching tool) that is used in LeSS, is System Thinking – something that helps understand various aspects of organizational design (e.g. local optimization) that may not be otherwise obvious.

References:

 

 

 

02/13-LeSS Talks: Co-Creator of Nexus (Richard Hundhausen) with LeSS Trainer (Greg Hutchings)

Shared Assets:

Additional Self-Study Assets:

Use of Velocity in Complex Organizational Settings

LeSS Scrum Master David Nielsen and I have discussed system dynamics in complex organizational settings, with respect to Velocity, produced by a single team and/or multiple teams.  We did only one cut (no dress rehearsals, dry runs or editing).
The following system variables were identified and their cause & effect relationship was ‘unpacked’:
  • Ability to use Velocity as a metric
  • Degree, to which combined velocity from multiple teams can be used as a measurement
  • Effectiveness of team’s estimation techniques
  • Likelihood that Customer/Product-centric development is valued, by business and the whole organization
  • Dependency on traditional organizational structure and protection of a status quo of component managers
  • Dependency on complex frameworks, processes
  • Degree of measurement dysfunction

As well as a few helpful proxy-variables to ‘glue’ the model together.

Download System Model (CLD)

Please, also refer to the following page on System Thinking, to make the best of the video and the model.

12/13-LeSS Talks: Case study about a LeSS adoption in Business Lending, by Cesario Ramos

Materials | Chat Script

Some of you may have seen this publication a few years ago, by Cesario Ramos: “… [Company] improves on the so-called Spotify Model using LeSS” that shined some light, from the inside, on what really took place.
[NB: As many people probably know, “Big Bank Spotify Model” success stories are being used by many large consultancies and companies that followed the advice]. Please, read about it: https://www.scrumwithstyle.com/ing-improves-on-the-so-called-spotify-model-using-less/

Synopsis:

“How do we use LeSS to further optimize the Spotify model; How to tackle scaling challenges with less. We will share our experiments, mistakes, and learning we got from adopting LeSS in a cross-border, dispersed team setting without Continuous Integration.”

Continue reading 12/13-LeSS Talks: Case study about a LeSS adoption in Business Lending, by Cesario Ramos

12/06-LeSS Talks: US Army’s Intelligence Staff Director COL Candice Frost on Crisis & Leadership

Colonel Candice Frost:

Synopsis:

  • An 80% solution on time is far better than a 100% solution late
  • Defining Problem Statement
  • Demonstrating a desire to create change
  • Providing a clear Vision into the Future
  • Leading by Example
  • Clearing Paths to Achieve a Common Goal
  • Changing is Constant
  • Building Strong Relationships
  • Providing Consistent & Continual Feedback
  • Giving Transparency

  • How excessive organizational layers, processes and approvals can lead to missing an opportunity
  • Importance of mentorship/education, as means of spreading knowledge laterally, to many people
  • Significance of striking a healthy balance between being a Specialist (know one discipline really well) and being a Generalist (knowing other disciplines fairly well)
  • Benefits of building long-lived teams
  • Keeping levels of “undone” work to a minimum and thriving to drive it to zero
Additional Learning Assets:

LeSS Trainer’s Class Experience Report: Product Definition, DoD & Team ‘Blueprint’ Exercise


This summary, is an experience report from the recently conducted online LeSS class (provisional CLP).  Specifically, this writing is about a few discussion topics, accompanied by in-class exercises and homework activities: product definition, definition of done (DoD) and teams (blueprint).

In class, we were lucky to have a few people that were already highly experienced with Scrum and knew fundamentals of LeSS. A few people were also from the same XYZ company (name withheld for privacy) that specializes in global ERP solutions for manufacturers. Among XYZ company people, there was a senior vice president of R&D and a few other senior-ranked technology professionals.  With everyone’s consent and for everyone’s benefit, we were able to discuss the above topics in the context of XYZ case.

It was also made clear to everyone that this exercise is merely a simulation of a much more comprehensive discovery process that takes place during the initial phase of LeSS adoption, with many more people involved, not just a few.

We started, by trying to understand the company’s big picture: vision, revenue steams, cost factors, product partnership (internal business, external customers, R&D), value, competition, innovation.  For that, we used the great facilitation tool, created by E. Gottesdiener – The Product Canvas.

After the first round of exploration (v1.0 below), it became apparent that the product definition was too wide (big), and it would be impossible to support its development by a single LeSS product group (2-8 teams).

Of course, this assumption was not conclusive but for the purpose of this in-class exercise, it was decided to reduce the product definition, by focusing only on one particular area – Sales (v2.0 below).  This was consistent with what is recommended in LeSS: to expand product definition as reasonably possible, but not make it too wide to manage.

In the second phase of product definition, the class focused on identifying user types and actions, as well as various product components: interfaces, data, controls, environments, etc. This further helped validating the assumption, made in the first step of product definition.

Following the product canvas use, to identify the most important (and big) product features, the class proceeded with a story mapping exercise. The following five large features have been identified: New Sales Order Interface, Shipping Dashboard, New Quote Interface, Data Layer. They were then further decomposed into smaller features that were prioritized, on a time scale.  The class had a quick conversation about what a minimal viable feature (MVF) could look like if multiple small features, from various buckets were deployed together (the curvy black line below).  Within a few rounds, many more small features were identified and bucketed under large features (but not prioritized). It was a shared understanding by everyone that all identified items, eventually, should end up in a backlog.

Next, the class tried to envision what Dominion of Done (DoD) could look like for a team that was tasked to deliver any of the above mentioned features. The attempt was made to identify those activities that would be still Undone (impossible to finish in a sprint) at the initial stage of sprinting and how important it would be to gradually expand DoD and shrink Undone, over time. The class further discussed differences between Unfinished work (usually, a team’s problem) and Undone work (usually, organizational problem).

Based on all of the information collected, the class tried to envision what technical skill set and functional domain expertise would be required, for each team, to ensure that each team could take any item from a backlog and get it to Done in one sprint.

Finally, the class (this part was mainly driven by people from XYZ company) tried to hypothesize what a team structure could look like (team ‘blueprint’), given that some developers had one and some – more than one, skill set and domain expertise. Everyone understood that this is just a hypo and the intention is not to assign people to teams prematurily, since managers, leads or anyone else should NOT be making decisions on behalf of on teams. The idea of self-organizing team-building workshop was introduced and discussed (a few published LeSS case studies were reviewed to better understand this event).

 

During the break, one of the class members (XYZ company) tried to blueprint what LeSS Product Group may look like if v1.0 model (illustrated above) was followed to describe the whole product.  It appeared that each Requirement Area, would have only between 2 and 3 teams. It was then discussed that this approach would  NOT be recommended, as very small requirement areas (with very few teams in each area area) would lead to organizational silos, compartmentalizing of work, scattered knowledge and local optimization.
The class further discussed R&D organizational design implications of XYZ company. Many HR aspects were highlighted, such as a developer’s career path, promotions, compensation/incentives, etc. Various HR-related LeSS experiments were  explained.

At this point, the class ended the simulation exercise, with understanding that in real life this process could take from a few weeks, to a few months. It was understood by everyone that before an organization makes a ‘flip’ to LeSS, some additional, very important milestones would have to be achieved:

Team Self-Formation Workshop:

Product Backlog Creation (Initial PBR session):
Preferably, a creation of an organizational impediment backlog – something, to be continuously attend to during Overall Retrospectives, where senior management, would take ownership of problems.

HR-Related LeSS experiments

 

XYZ Company people have demonstrated a lot of determination to implement many aspects of LeSS learning and discoveries ASAP, in real work settings, within their organization.