My world was running like a well-oiled machine.

I looked over my dashboards, flipping through tabs with a gleeful joy as I saw everything in its proper place. We had ten teams running good and proper Scrum by the Book™. All the standups were in a neat little cascade every morning, allowing myself and management to go from standup to standup like doctors making their morning rounds. Everything was being tracked and we had metrics for every little aspect of the project and product. I was seconds away from instant knowledge of any project we were working on.

All in all our transformation to agile was going supremely well. I couldn’t be happier.

“What’s that line there going down?”

Okay, I’d be happier if I didn’t have an 800 pound, invisible gorilla as a conscience.

I turned to face my gorilla. “Hogarth, it won’t work this time. Everything is going brilliantly.” I waved at the dashboards, “see, on time, on budget, etc. etc.”

The hulking form of Hogarth leaned over my shoulder and looked at my monitors for a few moments. Finally, he shrugged and looked at me. “For now…”

I goggled at him, “Can’t you ever be happy? Quit borrowing trouble from the future.”

Hogarth waved at my screens, “speaking of happy, isn’t the team happiness going down across the board?”

I grumbled to myself. A dozen metrics and he picks the only one that doesn’t look good. “Hogarth, we’re shipping more stuff than ever and it’s higher quality. More importantly, the agile transformation is a textbook rollout and working by the book™.

“So process is more important than people? I thought agile was the other way around?”

I blinked. Blinked again. Looked at Hogarth. Looked back at my screens.

“Umm…”

Healthy beats “agile” any day

In 2010 I started working for the Branded Products Group of Hitachi GST (now part of Western Digital). This group was responsible for taking the world-class Hitachi hard drives and putting them into consumer grade products. Or as I liked to say, “We’re building the kind of stuff you’d see on a shelf at Best Buy.” I was brought in to set up and run a program management office with a goal of establishing some predictable product release schedules. Hitachi itself had a massive Six Sigma, multi-year lead time, product lifecycle. Whereas the Branded Group was a recent acquisition that still was operating in what I call the Startup Chaos Lifecycle.

It was my first experience with consciously implementing agile practices and I have proudly held it up as an agile transformation example in the years since. When you look at the raw numbers you certainly can’t argue my efforts were successful. When I joined the company Branded was struggling to ship four projects a quarter. When I left, less than eighteen months later, the group was on track to ship over thirty projects in the quarter. A highly successful benchmark.

The question is, was it agile?

I wasn’t running Scrum or Kanban for the projects. Even in the small software team, our attempts at Scrum were highly questionable. We had weekly status meetings, not daily standups. We planned projects in an upfront planning cycle and stuck to them often despite reality telling us to stop. Our teams were operationally siloed instead of cross-functional. Almost everything you think of as “classically” agile was probably not being done. The transformation was certainly not Scrum, not Kanban and possibly not even Lean.

So was the organization agile?

Who cares…

It was healthy, it was producing rock-solid products, it was producing more per quarter than ever before and the teams had the best morale they’d ever experienced.

I absolutely believe that Scrum(XP), Kanban (and the new models emerging from both) are some of the best ways to develop products. And at the same time, I recognize that sometimes the organization is not going to be ready, able or willing to move to these agile frameworks.

Organizations, however, are ready to focus on healthy projects. Faster communication cycles will let us know if we’re off course earlier. Closer communication with the customer means we know if we are really delivering them the value they care about. Being flexible in our planning, instead of blindly marching off the cliff when we see the “Bridge Out” sign. If the organization is still writing big, upfront design documents or shipping on a yearly cadence, that’s fine, so long as they are putting a focus on the health of the project and teams.

And really, that’s what big letter Agile is about. It’s four values and twelve principles that tell us how we should work together on the delivery of a product. I’m constantly inspired by something Dr. Kevin Thompson said, in a Waterfall vs Agile panel many years ago. He was challenged that you “wouldn’t build a nuclear reactor using Scrum, would you?”. Kevin responded with “No, I wouldn’t use Scrum. I would, however, use the values and principles of agile in running the project.”

Having healthy projects is more important than the specific frameworks or methods we use. And following the values and principles of agile, even in a “waterfall” project is going to lead to healthier teams and more success.