It’s People

Back in 2021 I took a Lean Six Sigma Green Belt certification class. It’s been five years since I took that class, and I haven’t completed my Green Belt project to become an official Green Belt, but that wasn’t really my goal at the time (and, frankly, it’s still not a priority of mine, even though I still want to get my official Green Belt at some point). I took the class in the spirit of the 7 Habits of Highly Effective People, specifically “Seek first to understand, then be understood.” A few years earlier we had hired a new CFO at our organization who came from GE and had extensive experience with Lean Six Sigma. Our Senior Leaders, who I was working with on a regular basis, were being taught about DMAIC and how it could apply at our company, and as I was one of the key figures in determining how we executed on strategic initiatives I figured it was important for me to understand what was being taught to the folks I was working with.

I learned a lot when I took that class. I learned that Lean Six Sigma was predominantly used in manufacturing, specifically in finding ways to eliminate waste and reduce defects. I learned that Lean Six Sigma was not a Project Management framework, even though when someone attempts to improve a process using DMAIC it is referred to as a project. As someone who absolutely loves data, I was enamored by how much Lean Six Sigma practitioners rely on data analysis to achieve their goals. I learned that Lean Six Sigma was not anti-Agile, and that if done properly the two methodologies could easily work together and produce some spectacular results.

The most valuable lesson I learned, however, is about what I perceive to be a misperception around Lean Six Sigma. I heard, and was myself convinced, that it was a soulless way of looking at human labor. That it was very Taylorist in that it treated people as cogs in a machine, and that if they just did exactly what they were supposed to do and followed the right process everything would be perfect.

What I learned instead was that, in the Lean Six Sigma world, “People are never the problem. Your process is.”

What this meant, according to my instructor, was that if people were not following a process, it was because they were incentivized not to do so. That circumventing all or part of a process served their needs better than following that process. That, in most cases, people want to do a good job and do not avoid a process because they are bad actors. They do so because not following the process makes their lives easier in some way.

In other words, having good processes is incredibly important, but if you didn’t focus your efforts on serving the people who are meant to execute them, they were bound to fail.

Sounds kind of familiar from an Agile perspective, doesn’t it? Individuals and Interactions over processes and tools anyone?

I saw this play out during a senior leader meeting a few years ago. We were reviewing our homegrown enterprise work management process, and we were looking for input on how to improve it. We had printed out flowcharts that detailed all the steps required to get an initiative through the complete lifecycle at our organization. Our new VP of Application Development (so new that he had not “officially” started and had flown down just to take part in this summit), held up the piece of paper and folded it in half so that the start and end points were touching. “If I can do this,” he said, “and get my projects done without going through all of these steps…why wouldn’t I?”

He was right. It was possible to get projects done without going through all those steps, and in many cases a leader did so they were able to get things done faster than by going through them. I won’t go into the reasons why he was right in this post for a variety of reasons, but he very much was.

People are complex. I often catch myself saying that people are messy, but that’s putting a negative spin on the outlook and I try not to do that. Human beings are unpredictable, because we’re all unique. As individuals our actions and beliefs are shaped by innumerable experiences we have had throughout our lives, up until the very moment we are in at any given time. One person might be having a bad day because they spilled their morning cup of coffee, while another person might be having a great day because they thought about someone who did something nice for them twenty years ago. We’re a beautiful and chaotic mix that has been thrown into a blender and turned on to puree to make us what we are today.

No process in the world is ever going to account for that.

That does not, however, mean we shouldn’t try to optimize our processes. Quite the opposite! Part of the spirit of continual improvement is that we should constantly be looking at the ways we work and exploring ways to make them better! Lean Six Sigma is an amazing, data-driven tool that can help you do that. In fact, I would go so far as to say that it’s entirely possible to turn the outcome of an Agile Retrospective into a Lean Six Sigma DMAIC project.

Just don’t forget the people along the way.

Is it SAFe?

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…