Tag Archives: SAFe

When Agile Isn’t

agile word tiles

How much can we take away before it’s not what it was?

OK, philosophy time: When does a thing change so much that it ceases to be that thing?

Let’s Play Football, or Something Kind of Like It

Let’s take American football.  If I tell you I’m playing football, but that we aren’t wearing helmets or uniforms, is it still football?  What if we are using tear-off flags on our waists instead of tackling each other?  Still OK?  What if we have 5 players per side instead of 11?  What if we don’t allow forward passes (they once weren’t allowed, actually)?  What if we use a round football?  What if we don’t keep score?  You get the idea.  There’s some fuzzy point where the Reasonable Person of jurisprudence would agree “That’s … not football.”

For a more entertaining example of the difficulty of precise definitions you can check out the Sandwich Alignment Chart.  Is a burrito a sandwich?  I’ll warn you: it’s a pretty deep rabbit hole.

It Says “Agile” On The Carton But It Smells Kind of Weird

pouring milk

Can I drink this? Seems dubious.

Those of us who have been coaching Scrum, SAFe, Kanban or other “agile umbrella” practices for a long time tend to have a pretty good sense of when the basic tenets are being violated.  It’s tough to call out, though, because we also tend to want to avoid prescriptivism; if a team finds some change to a process works for them, great!  They are self-organizing, right?  Yes, but1 it’s OK to probe a bit into the intentionality behind the way teams are working.  Are they fully aware of the Agile Manifesto principles?  Are they professing to do a specific agile flavor such as Scrum?  How did they arrive at where they are?

1(pretend I said “yes, and” if it makes you feel better)

There are plenty of ways to go about assessing a team’s agile adoption.  For example:

  • You could administer one of the many team health surveys, such as the Spotify squad health check, or roll your own.
  • You could do an agile maturity assessment.  Ben Linders has a nice article on this and provides a mother lode of assessment links.
  • You could retrospect with the team and discuss the various aspects of Scrum (for example) and how much they feel each ceremony, role, and artifact is adding value.  You might be surprised at what you hear.

The important thing is that you as a coach or other leader are hyper-aware of how things are going so you can present and facilitate the right learning paths for the team.

What Exactly Is This We’re Doing?

“We’re Agile”

The more specific you get with with what you’re professing to do, the more you’re on the hook for the details.  This is probably why many people stop at “we’re agile” which in the modern world is like saying “yes, we develop software”.  So I guess those folks just need to live up to the Agile Manifesto and its 12 associated principles.  As long as the team talks to business stakeholders every day, works reasonable hours, has regular retrospectives, has regular face-to-face conversations, delivers software no less frequently than every couple of months, and … yikes does it really say all that?  Yep.

“We Do Scrum”

Scrum teams try to live up to the Agile Manifesto while also adopting more specific roles, ceremonies and artifacts: Scrum Master, Product Owner, daily standups, sprint planning and review, retrospectives,  and prioritized product and sprint backlogs.  They also follow the Scrum Values: commitment, courage, focus, openness, and respect.

I’ve been accused of being a prescriptivist when it comes to Scrum, but that’s because I’ve been able to help a lot of teams by getting them back to basics and investigating why they felt the need to skip retrospectives, not make the backlog visible to the teams, or whatever else.  It’s been pretty rare in my experience that teams have invented a brilliant new version of Scrum and pretty common that they’ve been cutting corners or just are not willing or able to commit to the mindset required.

“We Do 4-level SAFe 4.0”

If you know SAFe, you know it adds a slew of details on top of plain ol’ Scrum or Kanban.  It does a good job of explaining how to scale agile to many teams and defines processes that handle economics, coordination, shared resources, and medium and long-term planning.  However, if you’re going to say you do SAFe you should have Release Train Engineers, ART Sync meetings, Weighted Shortest Job First story ranking, and all that good stuff. You also get the 9 SAFe Principles on top of the Scrum Values and Agile Principles you’re already following.  You are decentralizing decision-making, right (#9)?

Labels Schmabels?

Only you can decide how you want to label your Agile implementation or whether you even want to at all.  Personally, I try to take care to be specific, like “We have a pretty strong agile program.  Most of the teams do Scrum but we have some Kanban support teams.  We’re still releasing on a long cadence though because our CI/CD and test automation practices just aren’t there yet.”

If I name a specific framework like SAFe, you should expect that I have a thorough working knowledge of the theory and can reel off the ways we aren’t in alignment with it, and for each I have some plan to get there or else a defensible argument as to why we aren’t going to implement it.  I think that’s only fair to the creators of those frameworks.  If I make no pretenses about named processes (“we’re rolling our own”) then it comes down to whether we’re following the agile principles.

It’s the Thought That Counts

I don’t think it’s helpful to go around pointing out all the ways teams are doing agile “wrong”. The reality is that it’s possible to succeed with or without normalized story points, or with two- or three-week sprints, or with all sorts of other minor modifications and variations.  However, in the spirit of reflection – “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” – I encourage you to be honest and open with yourselves and your teams about the current state of your agile journey.  Is it a work in progress?  Say that.  Does it feel like your agile implementation is in trouble?  Be forthright about that and get feedback from the teams and your leadership team.  And start with the values …

By far the most important goal for any agile team or organization is to work to embrace the chosen values and principles, whether it’s just the Agile Manifesto or the Scrum values or SAFe Principles.  Adoption of specific practices follows much more easily after that because (hopefully) they tie directly to the values and you can thus justify them in that light.  You can also self-evaluate your practices against the values.

In Closing: Is It Agile Or Not?

I have a hard time compromising on the Agile Manifesto and the twelve related values.  If there’s not at least an effort to live by those, it’s not Agile to me.  But certainly many companies happily implement Scrum, SAFe, or some other framework and just completely gloss over the underlying ideas.  That makes for a sort of Hollow Agile that often fails to deliver the expected results and leaves everyone feeling burned.

Don’t worry, there’s no Agile Police, so you can keep on keepin’ on without fear.  No one’s going to take your license away because you skipped a retro.  But I hope this post has helped you think about what it means to be agile and to frame what you’re doing more clearly to yourself and your teams.  Now get back out there and deliver some customer value!