I had two days of SAFe training this week. SAFe stands for Scaled Agile Framework. Its goal is to take Agile software practices and use them in a big program, big product, big system scenario.
The training itself went well. It was 10,000 times better than the training that I had 25 years ago on the Carnegie Mellon Capability Maturity Model. The instructor knew his stuff and wasn’t afraid to weigh in on the good/bad of how SAFe has been rolled out in our program.
But, I gotta say, the Capability Maturity Model took five vague concepts and enshrined them into a mythical religion. SAFe, on the other hand, took a whole slew of disparate imagery and jammed them all together in some of the most crowded, grindingly-bad metaphoric combinations I can imagine.
Starting with Agile
As it starts with Agile, SAFe is already on shaky metaphoric ground. In Agile practice, one breaks up the work into User Stories
. If a particular story is super-broad and long, then it is called an Epic
. So far, so good, eh? But, stories are fairly static and we’re trying to be Agile. So, we take a group of stories and put them together into the work we’re going to do for the next two weeks and we call it, an Anthology?, an Issue?, a Serial?, no… we call it a Sprint
. Because there is nothing like running with a good book to boost productivity.
And, I should mention that some User Stories
are more complicated than others. So, each User Story
has a number of Points
assigned to it, usually through Planning Poker
. We use a gambling metaphor to come to a team consensus on the number of Points
each Story
is worth.
Are you following me? Good.
Okay, so, in Agile, too, we want to break down the barriers between those who design and those who code and those who test. How does our team do this? We Scrum
. Scrum is term from the sport of Rugby. A scrum, in Rugby, is a big crowd of players from both teams, fighting over the ball in a mob, trying
to push it down the field to their team’s advantage. In Agile, we are all on the same team, so I’m not sure why we’re fighting over the ball. And, I’m not sure how this is helping us Sprint
our User Stories
. But, that’s what we do.
Really though, for some reason, we use the word Scrum
to mean a quick daily meeting to update everyone on what we’re working on and raise anything that is blocking us. Cuz, that’s nothing like a Rugby scrum. And, we use the term Swarm
to refer to those times when our whole team is focused on a singular goal to push it through, or when other teams dive in to help our team with a singular goal.
So, in order to finish our User Stories
in a Sprint
, we Scrum
every day and occasionally Swarm
.
And, like every good Sprint
, the next Sprint
starts immediately after the last one ends.
The last thing you do in a Sprint
is demo what you accomplished in the Sprint
. You know, like in a foot race, where you finish the race and then show everyone how you just finished the race. And, then, you have a Readout
of what you’ve done. And, you start the next sprint with a Readout
of what you’re going to do the next Sprint
. Because, it wasn’t scientific enough to have just finished your Stories
in your Sprint
, you need an old piece of galvanized steel equipment to spit out a small paper tape with the total on it.
All Aboard
So, how do you take something organized around Sprints
full of Stories
by a Scrum
team who can Swarm
and make it scale to something big?
Well, you start by adding trains. You add multiple, ARTs
(Agile Release Trains). These trains each have multiple Scrum
teams Scrumming
and Swarming
on Stories
.
But, now, we need some stuff in between Epics
and User Stories
. Are we going to stick with writing metaphors? Of course not. We’re going to make Epics
broken up into multiple Capabilities
and Capabilities
broken up into multiple Features
and those Features
get broken up into User Stories
.
Oh, we need to know where the Agile Release Trains
are heading, right? So, we will have a Roadmap
and a Vision
which will be the Guardrails
for our train. And, the train, itself, will be following a Value Stream
with Milestones
. So, your train doesn’t run on train tracks. It runs on a stream. It does this so it can Pivot
if needed. But, it is okay, because there are guardrails and a roadmap.
The train provides Transparency
. Your train full of scrums on a stream with a roadmap is transparent.
There is, of course, also a Product Manager or Product Owner who steers the train. We also have Release Train Engineers. They don’t get to steer though. They only get to drive the train straight along the stream.
Are We Flying Yet?
So, in Software Development, there are tons of small decisions that we make each day that, together, form the Architecture
of our application. Most big projects have dedicated Software Architects
who are responsible for keeping the Architecture
coherent.
You may rightly be thinking that this whole bevy of Scrum Teams
piled on our Agile Release Trains
with their heads focused on the User Stories
in their own Sprints
might not be the best thing for the overall Architecture
. But, that’s okay, because running along the Value Stream
there is also an Architectural Runway
. I’m not 100% sure if this is so that our product can fly (or land?) or so that our product can sell its new line of shoes in Milan. But, we’ve got a Runway
.
The Crooked House
At some point, someone decided that SAFe needed Lean. So, they added it in, too. In fact, they have what is called the SAFe House of Lean
. Now, I am quite glad that my house house does not lean.
The foundation of the SAFe House of Lean is Leadership
. The roof is Value
. The pillars are: Respect for people and culture
, Flow
, Innovation
, and Relentless Improvement
. We’ve now built a house out of abstract concepts. I’m not sure where it sits compared to our Stream
or our Runway
or our Train
or our Sprint
, but it makes for a hell of a User Story
.
I think software companies are trying to automate a process that can’t be automated: software development. It gets tiresome after a while. All the prescheduled meetings drive me nuts: the planning sessions, pre-planning sessions, “backlog grooming”, “stand-ups” (which I guess are now called “scrums”), “retrospectives”, and so on. You could cancel all of these. If a meeting actually needs to be held, someone will organize a meeting. Or people will simply walk across the room and talk to each other.
I don’t think the people who create these methodologies are insincere. But they should just get a regular job.
Finally, I think there is an impossibility theorem out there just waiting to be proved that says for any software methodology, there is a type of software that cannot be developed (at least not efficiently) using that methodology.
I agree with you on the Impossibility theorem or at least a CAP-type, pick two of three, theorem.
And, frankly, I don’t know if I have presented the term
fairly since I don’t get how the metaphor fits with anything. And, SAFe adds in a Scrum of Scrums where Scrum Masters from all of the Scrum Teams do a stand-up meeting twice a week.When your train is sprinting you must be careful not to sprint faster than other trains or your scope will stretch because relativity.