When I look at the diagram above, I get an absolute
headache. Yes, I’m one of those agilists who sees the Scaled Agile Framework diagram
and wants to absolutely claw his eyes out. Nothing in the above screams “Individuals
and Interactions over processes and tools” to me, and when I think about the level
of bureaucracy needed to support something as bulky as what is seen in this
picture I want to run screaming.
So, it might come as a bit of shock to know that I arranged
at Leading SAFe 4.0 certification class at our organization last week. I
recognize the fact that the structures around SAFe are very comforting to
people who are trying to transition from a command and control mindset, and I
have been challenged by my mentors to learn more about things that are counter
to what I believe. You know, that whole “seek first to understand, then be
understood” practice that is part of the 7 Habits of Highly
Effective People mindset. I’ve previously taken Scrum@Scale training, and (like Scrum)
itself it really resounded with me, but several of the members of our transformation
team really like the SAFe model. With all of that in mind, I set about to get a
better understanding of how SAFe works, and as a result I am, as of yesterday, a
certified SAFe Agilist.
That, coupled with all my other certifications and $5.00,
gets me the proverbial cup of coffee at Starbucks, and not even a venti one.
While I’m still skeptical about how something this complex
would work in our relatively small organization (our back-office staff is somewhere
around 150-200 people), I must admit that the framework isn’t all that bad. It’s clear that the creators
really did design it with the Agile
Manifesto in mind, and throughout the course of our two-day training I saw
many things that directly referenced back to it. One of which has been top of
mind for me lately.
See, in our organization we’re currently at a state where we
have been “doing” Agile for several years now. We’ve got teams outside of IT
using it. We have area leaders and executives involved in the process. We’ve
got a corporate Agile vision statement, and we’re working closely to align the
objectives of the organization with Agile practices. It’s all great stuff, and
I’m very proud of the progress we’ve made, but as we bring more and more people
into the fold, the question of “how do we know we are successful” keeps
cropping up. As the Enterprise Agile Coach, this is a particularly vexing question
for me. People look to me to explain to them how we know Agile is “right” for
us, and they want objective evidence to back up when I say that it is. This
frequently results in questions about what metrics we can use to show success, and
I loathe metrics. Well, let me
quantify that statement. I think metrics are fine as learning tools. I think
metrics can give teams data to use to improve. I’m not so anti-metric that I
think the practice of collecting data is worthless, but I do believe that metrics can very, very easily be distorted and
become useless. I can’t tell you the number of meetings that I have sat in
where a person who was presenting a metric did so by opening with “now keep in
mind that…” and proceeding to explain why, exactly, the metric they were sharing
was completely inaccurate and shouldn’t really be a factor in judging success (“but
it will be better next quarter”). When you’re talking about team metrics?
Forget it. Measure a team by number of lines of code completed? They add
unnecessary code. Tell a team they should increase their velocity? Suddenly all
the user stories that would have been 3’s become 5’s.
This is why, in the manifesto, there is a principle that specifically
addresses what “success” looks like in an Agile environment –
Working software is the primary measure of progress.
There it is. Simple. Clean. Straightforward. If your team is
consistently putting out quality work, the things you are doing are working.
What does all this have to do with SAFe? One of the things I
learned in our class, and one of the things that made me think that maybe SAFe
wasn’t quite the monstrosity that I
thought it was, is the fact that in the SAFe world the ultimate measure of
success is the System Demo.
The one
real measure of value, velocity, and progress is the demo of the fully
integrated work from all the teams during the prior iteration.
Not velocity.
Not burndowns.
Not ROI, or ROA, or lines of code created, or number of
tests passed.
Fully integrated work.
Teams getting things done.
I still take issue with the fact that, in both the SAFe
model and Scrum@Scale, there is an insistence that all the teams be doing the
work in the same manner (although SAFe did recently concede that some teams
could potentially use Kanban instead of Scrum). Frankly, I take issue with a
lot of the things that SAFe says you “have” to do to be successful
(prescriptive Agile makes me break out in hives), but it gives me hope that they
at least acknowledge the fact that no metric in the world shows success better
than teams producing quality work.
Agile isn’t a checklist, and your organization will never “be”
Agile if all you are focusing on is whether or not you can complete a menu of
items and say “yep, we did these things.” Some teams are going to thrive using
Scrum. Some will do better with Kanban. Some might just adopt XP practices, or
come up with their own way of doing things that works for them. That’s ok. That’s
great! The Agile Manifesto doesn’t say anything
about following a set of practices. What it says is that, in the end, if the
team is delivering value on a regular basis you should get out of their way and let them keep doing it.
Don’t even get me started on how to define “value,” though…
Like this:
Like Loading...