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