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.
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…