Category Archives: Uncategorized

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

May 15-17: Certified LeSS Practitioner Course & MeetUp with Craig Larman | NYC

Another mind-blowing and core-beliefs-challenging performance has been delivered by Craig Larman – the co-founder of Large Scale Scrum (LeSS).  This time, the class size has reached it’s record high (40 people), coming from various parts of the globe, representing different organizations, industries and cultures.  The walls of the biggest available, so far, training auditorium were completely (literally) covered with wizard paper, full of system modeling diagrams.

Some feedback and testimonies from Craig’ class, below:
“I wanted to thank Craig Larman for taking me through an amazing knowledge journey. If you work in a traditional organization and find yourself being frustrated and feeling like this is another ‘process of the month’ implementation and are constantly ask yourself WHY is this place like this, then this is the course for you. It’s a 3 day journey that spends a small amount of time on the mechanics on LeSS. And it’s the right and honest approach. If you want mechanics then read the book. As a coach, this course will give you the vision for organizational design for the next 50 years. This is the best money I have ever spent. Thanks again Craig and I promise I will read the three books 16 more times! PS… I’ve already read them once.”

Craig literally took all of us for deep freedive to the seabed of the agile paradigm. It’s refreshing to finally understand that agility, whether at scale or not, is explicitly about maximizing the organizational structure not added. Craig masterfully combines pragmatism with idealism, seasoned with an immense dose of experience and wit.
The class is basically a tour-de-force on systems thinking applied to software & hardware product development. One gets to clear the fog of local optimization in seemingly smart ideas such as component teams, team POs or specialized workers. The result is a simple, yet immensely challenging idea called LeSS. After the training one is ready to grasp just how big and necessary the chasm is to a better world of product development. I guess it’s up to each one of us to decide if we want to work on crossing that chasm, whatever it takes. Thanks Craig for helping me realize that!

Coming to Craig’s meet up is like a fireside chat. Very warm and very personal. The questions asked by the audience were incredibly thought-provoking and relatable even though they were from different functional domains. I personally liked the way Craig used examples from his vast experience to answer these questions. Once people get over the uneasiness coming from his comments, suggestions, and answers, I suspect they open their minds to many possibilities. There is something for everyone to learn, whether you are an entrepreneur, executive, manager or engineer. I look forward to seeing him again through this meet-up or another forum(s).

Anurag Saksena, Software Technology Lead


The training was wrapped with participation of Gordon Weir, invited by Craig Larman to share his past experience of LeSS adoption at Bank of America.

About Gordon: Gordon has been a department leader of technology groups in two large banks. And has first-hand experience of three LeSS huge adoptions (he doesn’t like the word “transformation”). All of them with very different contexts.  He talked about how he discovered LeSS and enabled it, and what he discovered during his multi year change journey. What didn’t work and gave personal anecdotes about how he dealt with the wider organisation’s persistent and unique ways of trying to force the org back to “normal”.


Additional Kodak moment are below:

November 17: Certified LeSS Basics (CLB) Course | NYC


Another Certified Large Scale Scrum Basics is compete!
Such an engaging and participating crowd!!!  Tons of provocative questions and complex organizational scenarios.
Some most intriguing and and actively discussed topics:
  • Seeing and Hearing Local Optimization
  • Feature Teams vs. Component Teams
  • Mentor-ship vs. Ownership
  • Individual motivation
  • Organizational Design implications on LeSS adoption
  • Organizational De-scaling as means of scaling Agility (and Scrum)

August 25: Certified LeSS Basics (CLB) Course | NYC

 

This class brought together people of different skill set and domain expertise: hands-on software engineers, managers and analysts, agile coaches, trainers and Scrum Masters. It was a high-pace introductory review of LeSS framework, with the focus on organizational design, system dynamics, LeSS principles/rules/guides, local optimization vs. global optimization, feature vs. component teams, LeSS roles and responsibilities, as well as highlighting most commonly seen anti-patterns in LeSS adoptions.
The students got engaged in structured (instructor-led) and interactive learning, mixed up collaborative break-out sessions and exercises.
Extensive Q&A was handled throughout the session, with many learning moments being related to organizational reality of modern companies.