Flavors of Agile - Do More with LeSS?

 

Large Scale Scrum, that is.

Take multi-team Scrum with a Scrum of Scrums, add Sprint Planning of Sprint Plannings and Retrospective of Retrospectives, and voila!

Okay, it may not be that easy, but it's close, on paper, when you want to explain it, at a high level, to someone who does not care about the details.

When you take a Scrum training class, you are most likely learning what The LeSS Company refers to as 'Single Team Scrum.'  I would amend this to 'Single Team, Single Product Scrum.'  I'll get to why, later.  For now, I'll just call it Scrum.  Understanding how Scrum works is your foundation to being able to scale-up Scrum.

LeSS offers two frameworks:

• LeSS - up to eight Scrum teams
• LeSS Huge - up to a few thousand people on one product

Regardless of which framework is used, there is a single Product backlog, one Product Owner, multiple teams, one sprint (at a time), all coming together to deliver one shippable product, each sprint.

How does LeSS compare to Scrum?  In leSS, Sprint Planning is split into two parts.  In part one, all teams participate and discuss how to split the work between teams.  In part two, the individual teams meet separately to plan their own sprints.  Daily Scrums are held by each team, and members from one team can observe another team's meeting in order to increase awareness of overall progress and share information.

Yes, there can be a Scrum of Scrums - optional , but beneficial.  Product Backlog Refinement combines all teams; it is not held separately by individual teams.  The same is true for the Sprint Review and Overall Retrospective.  It is worth noting that the Overall Retrospective does not require all team members to participate; just representatives from each team.  It can be different representatives, each time. 

Truth be told, I would still recommend individual team retrospectives.  Yes, it adds another meeting (and who wants that?), but each individual team will go through Tuckman's stages of group development - forming, storming, norming, and performing.  Once they are a high performing team, there are still minor adjustments that can be made and goals that can be set.    Without this, their representative may come back from the Overall Retrospective with goals and adjustments that the team did not agree to.

As you get into how to run LeSS Huge, the differences to Scrum start to grow.  IT still looks like Scrum, but it's not as organizationally flat.  A simple summation would be Requirements Areas, Area Product Owners, and potentially more meetings because more coordination is required.  The Product Owner breaks features down into Requirements Areas.  Separate Product Owners (Area Product Owners) own the Requirements Areas.  From there, it starts to look the same.

LeSS, of course, has its own set of principles that you are welcome to read about.  I can't say you'll find anything new or significantly different from other flavors of Agile, but they may help you understand the reasoning behind the approach. 

As I delve through the less.works site, I'm developing the opinion that a truly valuable tool in LeSS is User Story Mapping.  Whether you are using LeSS, or LeSS Huge, user story mapping provides a way to break up the work into related clusters that can be assigned to individual teams that all contribute to the finished product.

I think I found my new favorite (work-related) quote, which holds true for any flavor of Agile, or other approach to project management:

"There are no such things as best practices.  There are only practices that are good within a certain context."

The context in LeSS, as in many of the flavors of Agile, is Single Product.  So what do you do if you have multiple products?  Enter SLIM, or Scrum Lean In Motion.  If you visit the link, down at the bottom, you'll find that SLIM is a made up acronym, but the principle behind it may make sense, depending upon the context of your organization.  This principle is that, instead of scaling Agile up, you scale your organization down.

Does this mean dump products, or split the organization into multiple organizations that only focus on one product?  Is this even reasonable, let alone feasible?  I couldn't say, but I think that most companies would be unwilling to make such drastic changes just so that they could use a framework.  That would take well-quantified value, with the value being the goal, not the framework, so I won't say it's impossible.  My point in bringing up SLIM is to reiterate that organizational change is needed regardless of which flavor of Agile you adopt.  How much change can your organization tolerate?

This leads me to questions that I'm sure many others in a similar situation ask.  I work for a company that has multiple web sites, mobile apps, and back end systems that serve different customers, but are interconnected and, in some cases, share developers.  It is difficult to make a major change in one system without affecting another.  Do we have one product, or many?  We're embracing agile practices, where we can, but how do we take that step from release management to truly agile?

I've got a few more flavors of Agile to go, but I'm pretty sure they will be more along the lines of scalable single product variants.  As I wrap up the flavors of Agile, I'll put some more thought into multi-product approaches.  Hybrid comes to mind, first.  I'll deal with that in a future post.