agile approach

Two Principles for Scaling Any Agile Approach

Today, I wanted to talk about Large Scale Scrum, or LeSS.  We’ve begun experimenting with it in our organization, and I wanted to share my experiences thus far.  However, I felt I couldn’t.  It felt premature.  Before I could tell that story, I first needed to explain where we are, how we got there, and what motivated us to scale our agile approach.

However, I don’t suspect that’s a very interesting story for many of you.  Why should you care about a 100-person start up in Silicon Valley?  We’re not you, and you’re not here.  The context, the mindsets, and the people vary from one company to another, right?  What stays constant, however, are some simple principles so that’s where we’ll begin.

Make it work before you make it scale

At the heart of agile is continuous learning.  For every genuine success, there’s at least two failed attempts in our rear view mirror.  These mistakes are necessary, and we shouldn’t shortcut that experience.  The organization, the people, and especially you need to revel in every failure.

Agility is a cultural shift, not a rebranding.

Scheduling a meeting takes seconds so don’t judge success based on what ceremonies are on the books.  A true agile adoption takes time and often a great deal of it.  For us, our journey began about five years ago when an engineer began experimenting with XP.  Soon after, we began A/B testing new features so decisions could be based in data and not in ego or rank.  From there, it was a relatively painless Scrum adoption that began about 3.5 years ago.

Now, we’re deploying new features to our customers five times a day, and have begun experimenting with LeSS.  Does an agile adoption always take so long?  I don’t know.  In fact, I wouldn’t call ours an adoption but an agile evolution.  Our desire was to solve the problems in front of us and to get things done.  An agile approach just happened to be a means to that end.   Regardless of timeline, I would caution against scaling until you’re satisfied with the answers to these questions:

  1. Are our discussions about how we further leverage our agile approach or are they still about why agile at all?
  2. Are team members exemplifying T-shaped behaviors?
  3. Can everyone in the organization explain the intent–not just the mechanics–behind all our ceremonies?
  4. Do leaders believe self-sufficient teams are the centerpiece of the organization?

Strive for simplicity

We humans often confuse scaling with size.  We scale mountains.  Maps are to scale.  As such and as we grow, we should scale, right?  Wrong.  As we grow, we should simplify.  For example, look at Scrum.  It minimizes the number of functions in a team to three and no more.  It sends a subtle, yet powerful, message:

Put aside titles and focus on the mission, the customers, and each other.

For us, our Scrum journey began when we were about 30 people strong.  At that size, optimizing for the team was an easy decision.  Over time and as we grew, we continued to do so; however, optimizing heavily for the team also comes at a cost as I describe in Optimize for the Team–Sometimes.  As new teams came online, we accrued organizational debt little by little, and we began to notice ourselves slowly moving away from one of our company’s core values: Simplify.  We hope that our experiment with LeSS allows us to return to our simpler roots.

So far, our journey with LeSS has felt familiar, but it’s also posed some interesting challenges.  However, that’s a story for another day and for another blog post.  If you’re interested in hearing more about our journey, stay tuned, and if you haven’t yet subscribed to this blog, I hope you do so before you go.

Until next time.

Do you want to get notified when new posts are published? Leave your email below.

Leave a Comment

Your email address will not be published. Required fields are marked *