[Podcast] ​Approaching Things from an Agile Mindset

On our latest episode of The Agile Reformists podcast, MATRIX Agile Coaches Todd Sussman and Bruce Kuykendall discuss an Agile mindset approach.

Listen to the full episode or read the transcript below.

Todd Sussman: You've had significant experience working in large organizations and with some highly-skilled teams, so how has the Agile manifesto influenced your mindset and the culture of the organizations you have worked with?

Bruce Kuykendall: I feel that for software engineering, the Manifesto is still spot on, though it's got some gaps that need to be filled. However, I don’t really center it around my coaching, my training, or my mentoring anymore.

Not because I don't believe it, but because it's so software-centric, so I tend to take more of a values-driven approach to keep it simple.

I can’t recite the Agile Manifesto word for word and, frankly, probably couldn't remember but half a dozen of the 12 principles. I believe if you really want to drive behavior, it's got to be something memorable that sticks in people's heads, which they can use as a compass to guide their decision making.

TS: One thing I took away from the Manifesto, because it does have the four values underneath, is a guiding principle where it talks about individuals and interactions and working software and collaboration and responding to change.

It's really about embracing the dynamic nature of whatever you're doing. If you don't understand what the end is going to be, "I don't know what my event is going to be like, I’m an event coordinator,” or “I don't know what my hiring model and compensation model looks like, I’m an HR Director,” I can apply these Agile concepts to events or HR, so really embracing that dynamic nature, as opposed to the static aspects.

It's something that that has driven me, not necessarily memorizing, as you mentioned, the values are the principles; so, having them as a guidepost more than anything.

BK: I boil it down to trust, transparency, commitment, and relentless improvement. If you peel all those things in the Manifesto back, it really is built on that value system.

And you can always trace this function back to one of those things. If you're not getting transparency, you probably have a trust issue. If you're not getting real sustainable commitment, it's probably because you don't have enough transparency. So, you don't understand what your behaviors are and how they're connected to your outcomes.

And frankly, I can do a two-hour training and by the end of it, I can have everybody memorize trust, transparency, and continuous improvement, and it'll stick with them.

Then you build on that with three principles that I think embody all the principles of the Manifesto:

• Shared understanding: that’s really what the Manifesto was about. We want to build toward a shared understanding, rather than a defined set of requirements.

• Lean thinking. We want to have everybody within our organization think about how to eliminate waste right away, which will lead to improved flow and improved outcomes.

• Commitment to technical excellence.

The whole Manifesto is about shared understanding. It’s about focusing on outcomes, and to get outcomes, you have to understand not requirements, but what you are trying to accomplish.

But it goes deeper than that. Teams need to understand how they're going to do something. They need to understand how they're going to work together. And so that's a that's a principle that has to be followed. Then, lean thinking which really boils down to how do we eliminate waste.

And then commitment to technical excellence. Yes, obviously we can think of that in terms of software best practices, but what I love about approaching it like this is, I don't care whether you're in a marketing or HR department, or if you're building widgets in a factory, the values are the same.

Those three principles are the same, it's just different practices. And so, if we can, by founding our conversation around those things, within two hours we are going to have everybody in a room memorize and remember them.

If they forget everything else, if they root their decisions and those values and principles, they're more likely than not going to create a behavior that benefits their outcomes, rather than being dysfunctional.

There was a quote I heard in an Agile conference several years back that went something like, "your personal beliefs define your values, and it is those values that create the principles by which you behave and present yourself externally."

And if there is a conflict between your personal beliefs and the value system someone is trying to impose, it creates a lot of conflict.

I personally still find relevance in the Agile Manifesto and its 12 principles. I think they are very much aligned with what we've been talking about and that's where I go back to, we all have to have that anchor that allows us to take these values forward and allow us to behave in a manner that others can understand and expect based off of what we declare as our values. I think it's really a great way to be able to internalize it.

I think what we lose sometimes is this idea that if you just adapt this process, so if you just do scrum for example, all your problems are solved. But what we forget is organizations don't change. Teams don't change. People do, so by focusing on people, values and principles really do come through.

If people don't trust each other, you're not going to get transparency. If you don't have transparency, you can't get predictable commitment, because you don't know what's in your way.

If you can't get the predictable commitment, you certainly can't get to have a relentless improvement, so you must focus the people skills before everything else, because the rest is just technical stuff.

TS: That goes to the heart of what is the difference between an Agile adoption and an Agile transformation. Adoption is really replacing your existing process for a different process that kind of follows the Agile values to some extent “we are a scrum organization, because we do our daily stand ups and we do weekly demos, and we have sprint time boxes.”

I would think there's some value in that adoption, but transformation and the ability to change the way we think about approaching problems and the outcomes that we are ultimately trying to address, that's where you really get the benefit that Agile promises. The process just puts you in a position to take advantage of that mindset that hopefully you've created.

BK: How many times have we gone in and they’ve been doing scrum for years, and what they really did was start calling project managers scrum masters.

Then they just broke up all the requirements into what they call stories and started delivering them to weekly increments, but the mindset never changed so they didn't really realize a true value.

TS: Even worse, if you adopt the overhead of the transparency and the collaboration that comes along with any flavor of Agile, I would argue, if you just have a fixed scope fixed time engagement doing it in scrum, then that will take longer than what would have taken in the traditional manner, because now you've taken the overhead without asking for any of the benefit.

BK: Or worse. They become worse than waterfall. Now we're not going to actually do any analysis design. We're just going to go in and run rate code, and we go really fast, and so we try to integrate and then everything blows up because there was no plan.

TS: No cowboy coding. I’m going back to some of that technical excellence. I'm a firm believer that technical excellence is what enables Agility.

I think it was Dr. Edward Deming who said “It’s impossible to inspect quality into an application. It either exists or it doesn't.” Figuring out how to make that value important enough that we shift left inject quality from the beginning. As a developer, you're responsible for the quality of the code you produce. It is not QA’s job to tell you, you wrote high quality code. It's their job to tell you “if you solve these problems, then we will have a product that is of high quality and has hopefully that product market fit.”

BK: We want authors. Your job is not to write code. Your job is to solve problems. Your job is to tell a story in your code, and that's a different thought.

Stephen King isn't a typist. He is someone who creates an outcome. An outcome is entertainment. But it's the same thing. We want people who are solving problems that happen on a whiteboard. Typing code on keyboards is the last part.

And that's a different mindset.

TS: Coders versus developers or engineers. Depending on the word you want to use, writing functions and methods is the easy part. It’s the thought process that goes behind. How do you design it? And how do you do it in a manner that honors the non-functional requirements as well as the art form or the craftsmanship?

BK: Stephen King doesn't just sit down and write a book. He will look at a sentence and then say, “I want to change this word. It doesn't quite get the tone or the essence of what I'm trying to accomplish.” That's what a true engineer does as well. You go in and you debug and continue to massage and refactor until it's giving you the outcome you want, not just meeting the specifications.

TS: Where have you seen the most pushback and what are some of the ways that you've addressed it with these organizations that you've worked in?

BK: Where I get the most pushback is from the business side because they don’t want to spend all this money to get what they think they already have. So sometimes you have to start small to prove that what you're saying really is true at a low cost and then you can export that throughout the organization to the bigger pieces because they see the value.

TS: Absolutely. One of the things I tell product owners or business analysts that are going through some kind of training is to always imagine that your job depends on every story you write. Because if you write a large story that takes six weeks to implement and if it doesn't do what it's expected to do, that's a very different conversation than a user story that took four days to try something and didn't accomplish what it was supposed to accomplish.

BK: That goes back to lean thinking which is "fail faster". Because if you fail faster, it's typically a small failure.

TS: Absolutely. And you know tying it back to the whole idea of what is considered valuable. That has changed over the last 20 or 40 years, moving from the industrial age into the digital age, one of the biggest differences was that value system.

The industrial age focused on how to make efficiency, how to get more output for the same amount of effort invested, which produced major advancements in supply chains and factories. Whereas now that value statement is no longer how to optimize for efficiency but how to optimize for that market of one, the customer.

BK: And this is why simplifying makes more sense because the gap between the business and technology is almost gone. In fact, for the best companies in the world, it has disappeared. Every company is a software company. There is literally not a single industry that you could remove software and they were still standing on their own.

We can no longer think of technology as that department that's a cost center. It's time to bring them into the fold as a profit center and include them in creating outcomes and we all work with human values, rather than just binary code in terms of the binary solution.

TS: Employee satisfaction is an example of living those values because if you have high turnover and don't have a human aspect in your organization, it's hard to establish trust and it's hard to establish transparency because people are always looking over their shoulder and you will never get commitment.