Suiting Up for Agile Practice

Recently I've been looking at SAFe, the Scaled Agile Framework. The purpose of this framework is to apply agile methods at an enterprise scale, and not just at the coal face of development and delivery. You could think of it as a way of getting the higher-ups on board with agile practices.

Now, even from this distance I can tell that this last sentence has generated a response. I can hear some of you muttering "Not before time! Get some transparency into the boardroom quick. Get those overpaid suits away from their cocktail glasses and canapes and into some serious inspect and adapt cycles, and let them realize how much of an impediment they are!"Yet I see that others among you are choking on your coffee in indignation. "Fat chance of management ever becoming agile! Even if we tried to get them on board, what's the best that would happen? They'd just end up thinking they're agile while remaining as clueless as ever! Keep them isolated like the plague, and as far away from us and our work as possible!"

My own take on this is as follows...the glass is half full rather than half empty. Let's get agile practices into the boardroom, but let's also see it as an opportunity to get involved in driving its adoption. After all, the people with the greatest experience in applying agile methods are those of us who have been delivering value at an operational level. We have to be prepared to coach others accordingly...yes, that's right, even management. If enterprise frameworks like SAFe represent a vehicle for achieving that goal, then we should take a look at them and consider making use of them.

That's the mindset that I have adopted. I've looked at SAFe with a critical eye. The first thing I checked was how well it complies with the agile best practices that we have come to value "in the trenches". On that count, I'd say it was broadly compatible with (and consistent with) Scrum. However there appear to be some exceptions. I mentioned them on the scrum.org forum recently where they provoked some debate, and so I'd like to summarise them here.

Sprint Hardening

SAFe appears to support the practice of Sprint Hardening. In its training material it defines a hardened sprint as one which provides "an estimating guard band and resource flexibility for cadence". SAFe says hardening is needed because "some tests, validations, docs may not be practical every iteration". Personally, I admit to having used hardened sprints in the past, but I came to the conclusion that hardening was an anti-pattern. The problem (in my experience) is that it potentially compromises a team's Definition of Done. It instils the belief that things can be played just that little bit faster and looser because trickier things can be "swept up" later.

SAFe claims that hardened sprints are "not an excuse for build up of technical debt". That caveat seems to me like a tacit admission of the problems they can lead to. Even then, technical debt isn't the only gremlin that this practice invites. There's also debt around process, such as inadequate collaboration over incremental acceptance.

Stretch Goals

SAFe also appears to support the use of Stretch Goals, or Stretch Objectives as they are sometimes referred to. I have mixed feelings about them. On the one hand they are innocuous enough. Stretch goals are no different from "nice-to-have" requirements. They may or may not get delivered and they build a measure of contingency into a timebox which can be put to productive use. They are also eminently tradeable for higher priority work...such as the operational support duties that plague so many "project" teams in the real world.

On the other hand, Scrum says nothing about them, or indeed about budgeting contingency in any form. A team forecasts what it reckons it can do, and if it finishes early then more work can be brought forward out of the Product Backlog. The team members shouldn't be pushed beyond their comfort level...and seen in that light, "stretch goals" are anathema.

For me, the one thing I definitely don't like is the term itself. I see it as pointy-haired corporate speak of the worst order. Talking about "stretch goals" turns the timeboxed delivery of Minimum Viable Product into the hallmark of a mediocre team that can't or won't be "stretched", when it is actually the defining characteristic of a truly agile one.

What this means for agile transformation at scale

I've highlighted two small concerns that I have about the way agile practices are being positioned at scale. I want to make it clear that I do not consider either to be show-stoppers in any way. Neither of these concerns represent significant impediments for achieving enterprise levels of agility. It's just my own two cents on what I think is an important topic. Enterprise frameworks are taking off... SAFe is one, agility@scale is another, and DSDM is arguably a third. So let's ask ourselves the question: What exactly should "the suits in the boardroom" be taught about the practices we have used, so that they can play their own part in a more effective and agile way?