Great Kodak moment

LeSS was initially ‘mislabeled’; when it was called a scaling framework.
It is a descaling framework.It is also, organizational design framework that helps to address core elements of organizational design: HR policies, finance/budgeting, vendor management, site strategies – areas that are not too comfortable for many companies to address.System and Lean thinking drive understanding of LeSS.
LeSS is not about: ‘best practices’, maturity metrics, RAGs, KPIs, tools, and operating models.LeSS 3 adoption principles are:
1. Deep and Narrow (not broad and shallow)
2. Top – Bottom + Bottom – Up.
3. By Volunteering onlyWhat does this mean?Some uncomfortable questions that will be answered:
1. Why so few agile trainers and coaches truly understand LeSS and
teach it to clients?
2. Why large consultancies don’t bother teaching LeSS to their clients?
3. Why LeSS adoptions are not so widespread?

Today, Isaac is the founder and President of StarCIO, a services company that guides client success with data and technology while executing “smarter, faster, and more innovative” transformation programs. Isaac is a successful CIO who has led digital transformation, product development, innovation, agile management, data science programs, and machine learning in multiple organizations. His book, Driving Digital: The Leader’s Guide to Business Transformation Through Technology, is an Amazon bestseller and he has written over five hundred articles as a contributing editor at InfoWorld, CIO.com, and the StarCIO blog Social, Agile and Transformation. He is an industry speaker on digital transformation, becoming a data-driven organization, artificial intelligence, agile management, and other leadership topics. Isaac has been recognized as a top digital influence by IDG, Enterprise Management 360, and Thinkers360, a top 100 CIO in STEM, a top social CIO by HuffPost, Forbes, and HP Enterprise.

“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 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.

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

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.

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).

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”.

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.

(Originally published by Lv Yi on June 21, 2019) In this article, we shall look at a variant of the functional team and component team structures - a feature group. We shall revisit known dynamics of the functional and component teams, and see what’s similar and different between them and a feature group in terms […]