Why Is LeSS Authentic? Why Should Leadership NOT Exempt Itself from Learning LeSS?

Large Scale Scrum (LeSS) is the agile framework that has a history of implementations, trials & errors, experiments and experience reports collected and documented throughout a decade.
LeSS is Scrum, performed by multiple teams (2-8) that work on the same widely defined product, for the same Product Owner.
LeSS stresses the importance of organizational descaling (a.k.a. flattening) that needs to happen before agility can be scaled.  The first LeSS book (out of three published so far) was written in 2008 and it had incorporated the ideas of its two authors, C. Larman and B. Vodde, by mainly including their own experiences of initial LeSS adoptions, from years before.
Overall, LeSS journey has begun many years before Large Scale Scrum has been officially presented to the world and recognized, as a framework, and this is important to acknowledge.  But why?    

Because LeSS, unlike some other very popular and commercially successful frameworks, that are very easy to ‘unwrap and install’, was not invented re-actively, as a “quick fix/hot patch”, in response to growing market trends and business needs (commercial driver).

LeSS is authentic.  LeSS took its time to mature and cultivate, as a philosophy and way of thinking, not as a revenue-generating utility.  LeSS did it at its own pace, without a rush, while incorporating learning of many coaches and companies that went through LeSS adoptions, over years.   LeSS has naturally “aged”, in a good sense of this word 😊.

Important Point: Whereas, deep learning of system dynamics and organizational design is equally available to everyone who attends LeSS training, not everyone can equally impact-fully apply this learning, when they go back to work.  But why?

Lots of LeSS learning (through system modelling, using causal loop diagrams) touches upon organizational elements, such as HR norms and policies, reporting structures, career paths and promotions, location/site strategies, budgeting/finance processes, etc. – things that are considered to be “untouchable” for an average person (employee).

Of course, it does not mean that an average person is not able to start seeing things differently (they definitely do!) after studying LeSS but it is just that he may not have enough power/influence to make necessary organizational changes that are required by LeSS.  In fact, for many people, this newly gained knowledge which is no longer possible to “unlearn” 😊 (e.g. ability think systemically), is accompanied by realization of one’s own powerlessness – and could be pretty frustrating.

Things are different for people that occupy higher organizational positions.  A senior leader is able to combine the decision-making power that is given to him by his organization and the power of newly obtained knowledge, coming from LeSS training.  These two powers, united, can have an amplified effect.

Notably, a senior leader who wants to apply LeSS learning to improve his organization must have something else that is very special, in addition to just having general curiosity of the subject and desire to experiment: it is called a ‘sense of urgency’.  The best examples of senior leaders that have learned LeSS and then applied learning to reality, came from situations, where the need to change was urgent and separated success from failure.  Then, if the above is true, the formula of LeSS adoption success becomes:

(Organizational Power + Power of Knowledge)  x Sense of Urgency = Success of LeSS adoption

Important Point: It is strongly not advisable for senior leaders to delegate LeSS learning to people that are below them organizationally and therefore, not empowered to make organizational changes. Granted, individuals at all organizational levels will be benefited from learning LeSS (it is a great eye opener).  But senior leaders – people that are empowered to make significant organizational changes, must attend LeSS training in person and not delegate attendance to their subordinates.  Leadership should not exempt itself from learning.
In fact, and ideally, senior leadership should attend LeSS training, accompanied by their respective organizational verticals, so that everyone goes through the same learning journey together.  Having HR and finance people, alongside with C-level executives and staff members of lower organizational levels – is a HUGE BONUS.

Not All Scrum Anti-Patterns Are Easily Identifiable

This is not true Scrum!!!” – we often hear from people, pointing at omissions and pitfalls of fake Scrum implementations.  The list of classically seen Scrum anti-pattern could become pretty exhaustive.  Here are some examples of  “Dark Scrum” (as Ron Jeffries puts it):

  • Multiple people playing the role of Product Owner
  • No Scrum Master present or line manager performing the role
  • Scrum events are dismissed, in favor of status calls
  • PMO or first-line managers driving team dynamics , assign and monitor team work
  • Teams are understaffed and miss required skill-set to complete work
  • Too many translators-BAs that sit between real customers and development teams (see below)

But not all Scrum anti-patterns are equally obvious.  Let’s take a look at three instances of team-sprinting, where (1) Scrum anti-pattern is obvious, (2) Scrum anti-pattern is not obvious, (3) Scrum is done well.

Just before we proceed, let’s recap (paraphrase) what the Scrum Guide says: In Scrum, in every Sprint, a team delivers Potentially Shippable Product Increment (PSPI).  This is fundamental for Scrum.  In order for this to happen, each team must possess all necessary attributes (skills, knowledge, domain expertise) required to get work fully DONE (potentially shippable). This is what makes Scrum - real Scrum. Many teams that lack the required Scrum attributes still attempt to sprint, however, effectiveness of such “sprint-like activities” is significantly reduced.  Not all anti-patterns of Scrum are equally obvious.
Instance 1: Scrum anti-pattern is obvious
  • Separate, phase-specific backlogs or
  • Single backlog with phase-specific items
  • Local optimization by single-skill specialists (e.g. PM, BA, QA, Architect, Developer)
  • Hand-overs, toll-gates, “internal contracts”
  • Long periods of down-time by specialists, when it is not “their phase” to work
  • “Water-scrum” /” Scrum-fall”
  • Very weak Definition of Ready & Done
  • PSPI – takes many sprints to produce
Instance 2: Scrum anti-pattern is not obvious
  • Separate, component-specific backlogs or
  • Single backlog with component-specific items
  • Local optimization by component specialists (e.g. UI/UX, middle-tier, back-end, web service, architecture)
  • Hand-overs, toll-gates, “internal contracts”
  • Multiple non-development sprints needed to integrate all components and fix bugs
  • Weak Definition of Ready & Done
  • PSPI – takes many sprints to produce
Instance 3: Scrum is done well.
  • Single, shared, customer-centric backlog
  • Single, empowered Product Owner
  • Shared ownership of work, no siloes
  • Swarming by T-shaped people
  • Strong Definition of Ready & Done
  • PSPI – every sprint

For organizations and teams that are new to agile and scrum, did not make a required investment in proper training/education, have not made an effort to improve organizational design for better agility and do not have experienced agile coaches, supporting them in their journey, option 2 above, may seem as “OK way to sprint”.  But please, beware, that you are not getting a real benefit of true Scrum, when you have so much “Undone” work at the end of each sprint cycle ☹.

Below is a graphic illustration of the three types of sprinting described.

 

06/13 – LESS TALKS: Real life “war story” of LeSS adoption at Large Financial Institution

On June 13, Gordon Weir delivered his great presentation “Real life “war story” of LeSS adoption at Large Financial Institution” at NYC Large Scale Scrum (LeSS) meetup.

Here are some of the key points made in the presentation:

  • In 2006, there was a decision made to stop using the concept of a ‘project’, as this fake and artificially fabricated term implied start and end of something that was meant to be continuous: product development.
  • In 2007, there was a decision made to stop using Component-centric work and Release Trains – something that was mistakenly introduced by SAFe implementation
  • During 2006-2008 – the number of ‘feature points’ (equivalent to deployed features) delivered each sprint was pretty low. Introduction of SAFe did not improve the situation: too much ‘undone’ component-work remained at the end of each sprint
  • Between 2008 and 2009, Large Scale Scrum (LeSS) was introduced, and it led to a number of ‘feature points’ increasing steeply, every sprint
  • Closer to 2009, when 150+ development teams introduced SBE (specification by example), ATTD (acceptance test-driven development) and feature toggling (engineering practices that are strongly advocated by LeSS), a number of ‘feature points’ delivered each sprint grew even higher, with many teams becoming capable of releasing to production multiple times each sprint
  • Forming properly structured feature teams in NY, London, Kiev, Hyderabad and Hong Kong brought about the following benefits:
    • Reduced hand-offs: “concurrent engineering”
    • Clear accountability for feature delivery (by each team)
    • Code base sharing, across all teams that resulted in greater quality, evidenced by very minor issues, following latest release
    • Each team, focusing on one feature at a time – something that led to shared purpose and reduced task switching (ultimately leading to greater efficiency)
    • Teams, having greater appreciation for customer needs

Why did everything work? Because there was an environment of Autonomy, Fearlessness and good practices of software Engineering created.

Many companies start agile adoptions by introducing a long array of “agile processes” and “best practices”, falsely assuming that they are all universal or absolute.  But they are not.  Every company, every department, every situation has its own context.  Also, starting with “best practices” concept is wrong because hardly any of them are always “best”; rather “great” and only contextually.  Instead companies should start with introducing good principles that can be over time developed into good processes and practices that will always remain contextual.

The magic formula then becomes: Process + Practices = Principles + Context

Download Gordon Weir’s Presentation