When agile coaches have no access or influence with high-level managers, agile transformations won’t work; Zach Bonaker walks away from those agile coaching opportunities. Ryan Ripley observes that when low-level agile coaches teach engineers there’s a better way, and management won’t become agile themselves, many smart developers will leave the dysfunctional company and join a company with agile managers. We need new ways of communicating with executives, to help their companies become more agile and keep their best talent. 

This is a transcript of the Agile for Humans 003 audio podcast.

It is a follow-up to an article appearing in the Senex Rex blog called Agile Cancer: Stop Whining and Cure It.

Announcer: Processes and tools dominate today’s agile discussions, but we are devoted to the individuals and interactions that make it work. From the beginner to the veteran practitioner, we have something for you. Welcome to Agile for Humans.

Ryan Ripley: Hello, I’m Ryan Ripley. Joining me tonight is Zach Bonaker. Zach, why don’t you go ahead and do an introduction. We’ll jump right into the conversation. We’ve got a lot to talk about tonight, especially your most recent article. It’s pretty exciting, and we want to get right into that.

Zach Bonaker: Hey there. My name is Zach Bonaker. I’m a practicing agile coach. Right now I like to think of myself more as a benevolent trouble maker in my organizations, and I’m a big advocate and believer in agile as the next generation wave of business thinking. I first got involved with agile with a team around 2005, 2006 when doing the startup. It’s what first exposed me to the Scrum framework, and it just grew my interest from there. Since 2006 I guess you could say I’ve been accepting input from reality and responding to it. It’s guided me in my career, and it’s helped me through a number of agile transformation efforts, both large and small. Now here I am on my own trying to change businesses and make people’s lives better one day at a time.

Ryan Ripley: This article you did is blowing up, and I’d love to walk through it with you.

Zach Bonaker: Yes, sure.

Ryan Ripley: Actually, you’re getting some really good comments too.

Zach Bonaker: Oh, are you looking at it on LinkedIn? Yes, LinkedIn is my handy replacement for the fact that I’m not a great writer. I don’t think I ever have been. It’s not something that I really get passionate about. Everyone’s like, “Oh, you’ve got to get a blog. You’ve got to get these things going.” I just use that as my portal to have somewhat of a blog. Then I finally got shamed into actually starting to Twitter. It’s funny because I’ve been putting it off for years, just thinking, “I’m not going to really get into it,” and started it, and I’ve actually had a blast with it over the last few days. That’s one good thing. I’m glad I caved.

Ryan Ripley: It’s addictive though. You start pushing the phone for more updates and more updates. Then an hour goes by, and you’re just stuck in it. Twitter’s fun until you write something that people don’t like.

Zach Bonaker: Oh, and then you get abused?

Ryan Ripley: Then it gets interesting. Then you get … I’m amazed at the anti-agile movement that’s still out there. These people just hate it.

Zach Bonaker: I don’t know, man. I think part of it speaks to the heart of what I wrote in that article where we’re talking about is it an ignorance, is it a misunderstanding thing, or is it really just people lashing out at what it’s become and what they see? I don’t know, because it’s such a hard thing to disagree with, especially if you’re an engineer. Why wouldn’t you be in favor of it?

Ryan Ripley: Sounds like a lot of good stuff there. You are an independent then, out there contracting and working with multiple companies. Is that right?

Zach Bonaker: Yes. At this time, that’s the path I’m taking. My current client, the client I’m most engaged with, is actually 24 Hour Fitness. I’m with a gym company that is trying to take agile and really apply it to their IT organization from their internal software development practices and then promote that out through the rest of the organization. It’s very bottoms up. It’s been very challenging. We’ll see where this one goes. This is definitely a big puzzle we’re trying to solve. It’s been fun though.

Ryan Ripley: I think we first met up on LinkedIn, right? I think some discussions we crossed paths on. I really wanted to talk to you because when you make a comment, usually very insightful, a lot of lean thinking in it, not necessarily dogmatic Scrum. I always have appreciated that when you jump into a conversation and you share your thoughts there, so really excited to do this with you. Speaking of LinkedIn, you’ve dropped a bomb on LinkedIn with the subversion of agile, “agile is a cancer.” Very strong words, very interesting topic.

It’s a topic that I know as you noted in your article, Dave Thomas has really been speaking loudly about, and so have quite a few other agile advocates over the past few years. I’m hoping as long as you’re all right with it we can walk through and unpack that article, see what’s there, and go from there.

Zach Bonaker: Yes, I’d be happy to.

What led to this? What I find, at least in my experience, is that when I have an article like this flow from me, something has happened. Something has triggered it. A coworker said something, management has done something odd that has thrown me off on my thinking, and then a post like this appears. Is there a story behind the story? Is there anything like that, a little anecdote or story to share?

I wish I had a really brilliant answer for this one. The problem with me is I tend to be thinking about a hundred things at once and follow my own advice of limiting my work in progress, so all these thoughts have just been going through my mind that I’ve been trying to struggle with really what it was. Eventually, I stumbled on a video from Erik Meijer who was speaking out, I think it was right after Doug at Finland. It was at the beginning of the year in January. He gave this talk that … He’s a pretty inflammatory guy. At least he’s not afraid to make a statement.

And so he came out and said, “agile is a cancer, folks, and we need to remove it from the industry.” Right away my eyes just went wide and I thought, “What? Why would he say this?” I was hooked. Then it all came together when he was really, just really critical of Scrum. That’s fine that he can be critical of Scrum, but when we start talking about agile as a cancer, we have to remove it from the industry, it made me think back to Dave Thomas, where he said, “agile is dead. Long live agility. It’s time to just let go of the word agile, because it’s been subverted, in his words, to something that really these days the agile community is just a bunch of consultants and vendors there to hawk their services and products.

That’s when it really all came together for me. I was inspired to write this article because I felt like I had put my finger on a pulse of something that for years I was thinking about. We’re pursuing the agile manifesto, yet we’re discovering that it has larger organizational implications, and we’ve struggled with our software background to talk to non-software people and make them understand what that means to be agile. That’s that, when he says agile is cancer, I think that’s what he’s talking about, is that agile cancer inhibits our ability to progress, to tell the executives and to get them on board to create agile organizations, not necessarily just an agile department or a set of agile teams.

Ryan Ripley: Do you think it’s a communication block between I guess agile advocates and traditional managers? Is that where the separation is?

Zach Bonaker: Yes, it could be. I mean there’s a lot of people out there, and I lead to this as I think one of the biggest pain points in the article where the catch-22 that we have these days is that we have managers that want to be benevolent, they want to do what’s right, yet they’re also very prideful and have been doing things their way for a long time. They hear of the benefits of agile, and they try, and they’re unsuccessful in doing so. Instead of seeking help, they define … So without even really knowing their problem, they then create the job requirements for people to come in and solve the problem. Then you get recruiters that are getting misinformed basically, and it just creates this cycle. We’ve got an industry, and it’s hard to blame the people who wanted to capitalize on it.

I understand that part, but we’ve got a very … What is an agile certification these days? We’ve got an easy to get, easy to sell certification mill that adds to that noise. We’ve got this whole cycle where people have been unable to solve their problems, and they haven’t in an agile way asked for help to collaborate with people to discover it. We’ve just been trying to define it. I think, again, this is this cancer that Meijer and Dave Roberts they’re talking about wanting to eliminate. It’s that ignorance. I’ve always thought it’s that ignorance in leadership in trying to grow agile. Does that make sense?

Ryan Ripley: Yes, I think it does, and it’s a thought that I’ve had lately. It’s actually part of a conversation I was having today with peers and other managers; I view agile as a grenade. Your metaphor is cancer. I think it’s a grenade that we drop in an organization. It blows up, but instead of damaging people, it does good. It’s a benevolent explosion, but also it can be painful. I think it’s very scary to people, especially in leadership structures and heavily organized structures where power could be lost, influence could be lost, prestige, whatever it is that a typical manager, director or V.P. has. Now we’re shaking that up.

We’re shuffling the deck and saying, “No, the center of this organization is now the product. It’s not the org structure.” I really think that that terrifies people, and it created a market for these consultants and vendors to come in and say, “Look, we’ll make you agile. We’ll satisfy your shareholders, and you don’t have to change a thing.” That sells like crazy, right?

Zach Bonaker: Yes, right, I want agile. It’s like a quote from a vice-president of a very, very large company. This is one of the quotes I chose to use in the article where he said, “I want agile.” He was like, “Here’s what I need from you, Zach. I need you to come in, I need the benefits of agile, but you’re going to have to do it in a way that doesn’t change anything, right? I just basically, what we need is we need to get better at what we do. I need agile to work with today’s processes and without changing the organization,” and I just shook his hand and said, “Good luck with that. I can’t do it. I’m sorry.”

Ryan Ripley: Basically, I want double the productivity at zero cost.

Zach Bonaker: Yes.

Ryan Ripley: Excellent.

Zach Bonaker: That’s a lot, at least in my experience. I guess I’m one of those unique consultants these days where I’ll go out there, and I’m not trying to get the job so much as I am trying to make sure that I’m comfortable taking the job. When I ask people, “What’s off limits to me in the organization … If I come in, is there anything that’s off limits?” If they say, “Yeah, yeah, you can only work in IT,” then I’m like, “OK, good luck, goodbye,” and walk out the door. It’s the idea of do you want to be really great or do you just want to be mediocre? So I’m not afraid to say no, but what I’m seeing out in the industry, and I talk with a lot of the organizations, is that agile really is perceived to be a software thing. It’s an engineer thing. It’s a worker-bee thing. I couldn’t even say it’s like a management fad. It’s literally this perception from people in management, those that are bringing people on to help with their agile needs and wants, and it’s just, “Make the workers do it,” and they don’t want to change. “Don’t tell me how to do my job. I’ve spent 20 years to get to this position. I’m a very smart person. Don’t tell me what to do. Make them do it.” Those are the people that I’ll say, look, I’ll try to overcome the objection and help them understand, but then I have to walk out the door. That leads me to a whole theory of what I think our next wave of pursuing our agile knowledge is.

Ryan Ripley: What do you think that is? What’s the next step that … In your case, you’re walking away, and I think that’s right. If a company’s not willing to look at the big picture and a transformation, you can’t be successful. You will ultimately fail after … I think it’s possible to get a performance bump by energizing people with the promise of something different, but it turns into a fake pitch, right? I mean you’re …

Zach Bonaker: Yes. Yes, it’s very disrespectful of us. There’s also a threat. I learned the hard way with a company when I was getting going on doing this on my own where I took that … I dove in. I said, OK, it’s everything is off limits. It’s going to be entirely bottom up, but what I’m going to do is I’m going to do just like you said. I’m going to teach these people what’s possible and get them to think in new ways. When they realized their management wouldn’t change, they all left.

Ryan Ripley: Yes, I mean that’s a dangerous …

Zach Bonaker: That’s not a good thing to do for … I felt terrible about it, but it was …

Ryan Ripley: I’ve seen that exact situation before. I know a number of consultants that I’ve talked to who have said the same thing. “We taught this group a better way. Their eyes opened up, and when they realized,” like you said, “Management’s not changing, they bolted.” All of a sudden, you lose five to ten engineers, very bright people at the core of your product, that’s pain. Very interesting. It seems to be a common trend. I think it’s great that as a consultant you show the integrity to walk away from those situations because you know it could even damage the client. It’s too bad that more don’t. Aside from walking away, is there a path through? I guess the nut to crack in the next wave of agile is how do you get business and management on board?

Zach Bonaker: Yes. Did you intentionally leave bread crumbs for me? That’s just about the most perfect setup. Like I said, I’ve been thinking. I think about a lot of things. Over the last few years, I’d struggled to understand what it is I was trying to understand, until I realized it was that we have a manifesto for software development that speaks to our engineers, and our developers, and our people that way. It doesn’t enable the conversations that we need to grow and to scale agile, to grow beyond.

I mean if you’re just a small company, maybe it works, but what about a company that’s got 20 different verticals with 20,000 employees and they want to get the benefit of agile. Maybe it’s not just software that they do. How do we become agile, and that’s the idea that we need a … I don’t really mean a manifesto, but we need something like a manifesto that describes an agile organization and that’s, boom, this clarity, this moment happen. I’m going to completely … I’m not working for him, but all the credit is going to go to him here.

I had a conversation then with a very, very amazing thinker, a great colleague by the name of Dan Greening. Hopefully, some listeners out there are following Dan Greening or know Dan Greening. He’s currently collaborating with Jeff Sutherland, and they’re both going to be speaking at Agile 2015 on the agile base patterns, the base patterns of an agile organization. I went, “Ah, that’s what I was looking for.” I got in touch with Dan, and I showed him my pillars that I had defined, and he shared with me his.

I think that this is really cutting edge stuff that is changing my mindset. It’s changing other people’s mindset of realizing we know how to talk to teams. We know how to talk to product strategies, and product owners, and people like that about growing agile teams, but how do we talk to the organization about agile? This is where these base patterns come in. Check out Dan Greening. Listeners, go to his site. It’s senexex.com. Read his blog and just take a look at the stuff. I’ll introduce it here, but this is really what’s at the forefront of mind these days.

I think this is the next step, where we look at an agile organization and we say, “What are their patterns?” The first thing that an agile organization does is that they measure economic progress. They have an economic framework for … Companies go, “No, no, no, we do that. We do a big feasibility study with a big ROI projection.” We’re not talking about economic guesses. We’re talking about economic measurements. Do we prioritize using an economic framework, and do we get the feedback on our initiatives in an economic stance so that we know if we’re on the right track or not?

First they measure economic progress. Second they proactively experiment. This could be a culture of continuous improvement, but they’re not afraid to try experiments to gain a competitive advantage. We want fast feedback. We want to amplify our feedback loops, so we’re going to proactively experiment.

Third is the agile organization is going to limit their work in progress. That’s great, we’re going to design systems of work that incorporate pull methods, not push methods. We’re going to get away from big phase-gated batch work.

Maybe I’ve got 20 initiatives that I want done and I’ve got 5 teams. I’d better not have 20 initiatives or 20 projects in progress. We’re going to limit our work in progress. We’re not going to mistake activity for accomplishment. Only done is done. Fourth, and this is where we start getting into the management culture. We’re going to embrace collective responsibility. What does that mean? It means if there’s an outcome that happens at a team level, we ask ourselves collectively, “How can I be responsible for this?”

If I’m a manager and my teams, they fail on something, I’m going to first ask myself, “What did I do to possibly contribute to that? Did I do everything I could? Did I give them the environment? I’ll take collective responsibility for the outcome instead of point fingers at the teams. “Hey, coaches, what’s going on? We brought you on to make the teams be successful, and they’re not. What’s your problem? What’s their problem?” Collective responsibility. Then the last and the fifth is that they solve systemic problems, meaning they get to the root cause. Agile organizations don’t scratch the surface. We’re not afraid to dive deep, and we may look for solutions that go beyond our teams and our departments.

We look to solve the problem systemically. These are the five base patterns that Dan has been experimenting with and discovering, and I think this is it. I think this is how we engage executives, vice-presidents, business people with agile. We know how to talk to developers. Those five base patterns I think speak more to the business side, that we can understand this is who we are if we’re an agile organization. I think that’s part of the step of curing the agile cancer, the perception that it’s just a development thing and it’s not an organization, it’s not a people thing.

Ryan Ripley: Isn’t that still difficult to walk into a CEO’s office and say, “Yeah, you’ve been doing this for 100 years as a company. You’re successful. You’re on the Dow Jones,” or whatever. “Your stock is in the stratosphere, but you want to be quicker, so we’re going to blow everything up.” Isn’t that still … That’s the part … I agree with the five pillars. I think those are brilliant, or the five areas or methods. Those are the … What did you call them, practice patterns?

Zach Bonaker: Yes. Dan’s calling it the agile patterns, the base patterns.

Ryan Ripley: I think those patterns are emergent in teams that embrace, I think Lean more than necessarily Scrum. Those companies, they start doing well on the software side, but when you break down … I’m going to have to edit part of this because now you’ve got me thinking.

Zach Bonaker: It’s good stuff, man.

Ryan Ripley: It is. I’m just trying to think, how do you jump the org chart? How do you get to where the business says, “Yes, it’s a good idea to tear this down. Yes, we want to see collective responsibility, but I still want to drive an Audi, I still want a 30% bonus, and I still want to take my kids to Disney every year”? How do you get through that? That’s the question that’s occupying my brain lately. I’m not …

Zach Bonaker: It’s a great question. If we’re going to think and we’re going to take an agile stance, we’re going to really value the individual, the interaction first, and we’re probably going to accept that people are very complex creations. I don’t know if there’s ever going to be a silver bullet to have this conversation, “Here’s a way. Here’s how we’re going to engage people to make this happen.” I think we can use these patterns to create a framework, and I think we need to … Whenever I go and I sit down and talk with an executive or somebody, first I just want to know who the person is.

I want to value them. What are their fears? What are their beliefs? What are their concerns? Who are they as a person? Sometimes you discover that really what they are interested in is something outside of the workplace so, great, everyone loves stories. I can tell a story about that and connect it to a different way of work that maybe gets them engaged. There isn’t an easy way to solve a person problem because people are complex, but I really love these patterns because I think it helps us discover frameworks or I guess space that we could have these conversations. I’ll tell you, when you figure out how to talk to a CEO perfectly about an agile transformation, let me know; you’ve got the silver bullet, and I’m going to work for you on that one because you’re going to be successful.

Ryan Ripley: Yes, I don’t think there’s necessarily a silver bullet, but I do like your concept of finding out their fears, their values, their beliefs. I love the concept of actually trying to develop personas around managers, and directors, and VPs, and CEOs, and even trying to figure out who’s movable, who’s a mover, and who’s immovable. You have those three types of people, and if you can get them shuffled into the right spots, you figure out who to work with, who to network with, where the pathways are, and I think that’s why there isn’t a silver bullet, as you said.

It’s just that it’s so fascinatingly complex. I still think those five agile patterns feed into value. I think that’s where we get our traction. If you walk into a CEO’s office and you say, “Look, this is going to be a hard pill to swallow, but at the end of it we think we can gain 30%, 40, x-% percent value,” you at least have their attention, but then you have to prove it.

Zach Bonaker: Yes, but the great thing about that is that if you can start that conversation … In my article I even spoke to it saying, “Hey, as a leader it’s OK to say I don’t know.” Instead, surrender to your problem. Surrender to your problem, elevate it, and then dialogue. I’ll tell you right now, I’ve been successful with some executives, and I’ve been terrible at convincing other people. I just couldn’t connect with them. I’m not afraid to say, “I don’t know. I don’t know exactly how to solve it,” but when we do engage that top level, the leadership level of an organization, we get them thinking agile and wanting it.

Then we create a top down transformation. That’s such a powerful thing, because when executives demand agility, they get it. They get it, and their people below start to just respond accordingly because we’ve got these respected individuals above that are demanding change, so they’re going to please them and they’re going to go for it. A top down transformation is … There’s so many hurdles to overcome in a bottom up, so many hurdles, and objections, and sales pitches. It’s such a challenging thing to do.

A top down transformation, that has so much more potential there. If we can use these base patterns and we can tell a story around them with leaders and maybe walk them to getting to that vision, that place, that better place, that better, happier organization that’s more successful, to tell a story around that, maybe we can get them invested, then we create a top down transformation, that’s what we should be pursuing, more top down, and I believe this, more top down transformations to increase the amount of success stories that we have out there. We have so many failure stories of agile transformations. When you go back and you look at them, they’re always bottom up. They always are.

Ryan Ripley: Yes, it is truly difficult to go from that grassroots all the way up to the top. I’ve seen the same kind of horror stories that you’ve mentioned where it started with great intentions. Developers wanted to change the way they work, business resisted, huge epic fights, lots of firings, lots of failure, and it’s truly not a lot of fun but, yes, I agree. You’ve got to go top down. That’s where you find the big successes, at least I think in our experience. It’s just, it’s the authority, and you have to start with that. The ability to fundamentally change a company doesn’t come from the bottom.

Zach Bonaker: Right. How did your transformation … How did you get … Where did agile come from at your place of work today?

Ryan Ripley: Here’s where I contradict myself. The last transformation that I did was at one of the larger hardware wholesalers in the country. They were looking for a better way to deliver projects, because basically their project portfolio was in not great shape. I was brought in, in a project management role, traditional project manager role, inherited a project that was way over budget and running way behind, a very angry customer, and I was given authority to do whatever it took, including implementing Scrum, to get the project back on track. I said, “That’s fine, but we’re going to work in a certain way. We’re going to implement certain patterns, and it has to be in an agile fashion where we have as a team the authority to make quicker decisions.”

I got full buy-in from all the way up to the VP of IT and they said, “Do it.” Within probably a three month period after we delivered the third sprint … We started at a four week sprint, modified Scrum, so it’s Scrum Light just to get the team moving, thinking. Got the customer back in the room, who was not really thrilled at first about talking to the team after months and months prior to my arrival going badly, or things going badly, and all of a sudden we made three deliveries of good code, of features that they needed.

That got a lot of attention. It was amazing what delivering three or four value added features did to the perception of the team. Now all of a sudden, the team is energized. They’re excited. They’re finding success after months of struggle. Business is excited. They have a feature that added immediate value back to their process, and my management is just totally almost relieved, like we got code out the door. What baffled most of them was, “Well, wait, the project’s not finished. How did you release?”

You start having those kind of conversations and then suddenly, “Hey, we want this,” and it went all the way up to the CEO from the VP of IT and they said, “Yes, this is what we want to do.” It got to the point to where we actually were doing planning poker, what I call planning poker in the boardroom, which is a post I need to get out soon, where prioritizing enterprise-wide goals and projects is done with planning poker cards. We’re going to estimate the value. We’re going to estimate the effort at an executive point level, create a backlog, and then push that down for other teams to work on.

It’s working amazingly well. They’re making decisions quickly. They’re inspecting and adapting those decisions constantly. They’re getting the right projects done in the right amount of time, delivering the necessary value at that moment they need it. Incredibly effective, but it started in desperation. Project in a tailspin, and they gave the authority to do what was needed, and it’s that quick victory that led to that enterprise-wise adoption.

Zach Bonaker: Yes, that’s really interesting. You’ve got an example here of a bottom up success story, but I think there’s an important thing there that enabled it, is that there was desperation it sounds like.

Ryan Ripley: Maybe desperation’s a strong word. I think there was just a real big desire to not have this project fail. It was an application that was 20 years old. In order to … The server was outdated, but they couldn’t change the server because the software would only run on this certain architecture. To actually maintain the app, they would have to go out to eBay to try to find parts for this box. It’s one of those things, and it was running a key process to a four billion dollar company. If this system goes down, product stops getting sold. It was this horrible central point of failure so, yes, maybe desperate is the right word. It needed to get replaced quickly.

Zach Bonaker: Or at least it’s that … Because I’ve observed this. When you talk and you try to introduce agile really at any level, there’s always people who are just new. They don’t have biases. They’re not thinking in a dogmatic way, and they’re just sponges, ready to try something. “Cool, I’ve got something for you to try.” Then there’s people who have nothing to lose. It can’t get any worse. It can’t get any worse. They’ve got nothing to lose. Those are great places to be. I think bottom up transformation, hey, if we’re really at that place then, yes, we can become successful. I think, at least with the current engagement that I’m at with my client, for them it wasn’t a place of desperation.

It was some people asked for it. It was like, “Well, will that make them happy? Yeah, let them do it.” That’s not a place of desperation. There’s not a place of a unity of purpose there in the department to make this happen so, yes, in those kind of cases, bottom up is really a struggle. It’s great that you were able to actually get a bottom up that went all the way to the top and caught on. I think it’s amazing. It’s like at the leadership level you have a strategic Scrum team building a backlog and working the same way that their teams do, yet it’s driving the organization. That’s awesome.

Ryan Ripley: It is.

Zach Bonaker: That’s certainly inspiring for me. I love to hear it.

Ryan Ripley: Yes. What’s interesting is, I don’t know if … I think it is part desperation, but what really made the difference, and I think this is common across a lot of transformations, there is a clear sense of urgency, that something had to change or else this was going to be catastrophic. When that presence isn’t there, bottom up certainly can’t work. In the case that I just laid out, the reason that bottom up worked is that I had authority from the top down, so there were no barriers. There was a direct line to all the way up to C-level people saying, “If you need something, say it, and we will do it.”

There were no barriers, no problems organizationally. There were no blockers. It’s a very flat org, so those were perfect conditions for a bottom up engagement. It’s not something I would recommend in many cases, and it was a surprise to me. I actually took a job as a traditional PM expecting to do some hybrid waterfall nonsense that we’ve been doing for the past 50 years. When that opportunity emerged, it was excellent.

Zach Bonaker: Yes, so if you look at what the environment was like from that base patterns perspective, let’s look at it. Adaptively experiment. I mean like you said, you started with something that was Scrum-like, and it sounded like you grew practices, so you started with some small experiments to figure out what was working to gain traction, so that was great. You’ve got the leadership that you said you could go to for support. They didn’t say, “I don’t care how you do it. Just get it done.”

They said, “No, tell me what you need, and I’ll help,” so it’s a bit of that shared responsibility. You were limiting your work in progress obviously by using an iterative method and trying to focus on delivering. You created the … You started demonstrating some of those patterns that made it successful. You’re touching on the fact that it went beyond just the team to make it happen.

Ryan Ripley: Yes, it fundamentally changed the business as well, so on the product that … First of all, just naming a product owner was huge. This person has the authority to guide the product. From that point forward, the business started thinking in vertical slices of an application instead of a big bang, which is also very critical. We have to slice this thing from the UI down to the database and understand the fields and the data driving what we want to do. That was also important. Then like I said, from the C-level, they all have a deck of planning poker cards, and they are honestly driving a company through affinity estimation. It really is awesome to see.

Zach Bonaker: Yes. A colleague of mine has a great quote. He goes, “I seek something that gets my tank full every day, like I’ve got to feel like my tank is full. Otherwise, I run out of energy.” I think you just did it for me, Ryan. I think you filled my tank today, just giving me a vision of people in a boardroom, executives in a boardroom saying, “All right, all right, let’s pull out the planning poker deck. Let’s estimate.” That’s awesome. That’s really cool.

Ryan Ripley: I appreciate that. It really is, it’s a neat thing to see, but it’s also it was amazing to see people in that position just admitting that estimates are kind of garbage. We acknowledge that, hey, it’s an estimate. It’s likely wrong. The only thing that’s perfect are actuals, and it’s too late then, so we’re going to do this quickly. We’re going to try to understand the value instead of a cost or a duration, and we’re going to go forward. It really is a neat change, and even from that point of view. The typical project, they want to know the cost up front. They want to know the duration up front. And by ‘they’, I just mean traditional management.

Then you’re allowed to do it if it all fits within some preconceived date. In this case, they just shook that up and said, “Well, the cost is fixed because we have a Scrum team that has a run rate, so we know the cost. So that part of the equation is fixed, and we know pretty much what the value should be, because we’ve taken the time from a product owner perspective to do some due diligence and know what the system could generate. So long as X is greater than Y, go do it, and we’ll basically keep the scope flexible.” Totally turn that iron triangle on its side. It’s no longer fixed scope, fixed date, fixed cost with quality being the only lever to pull. Now all of a sudden, it’s just value that you can enhance. It really did open eyes and blow minds. It was really a neat path they went down.

Zach Bonaker: Yes, very cool, very cool. Like I said, it fills my tank. I’m good. I’m good for the rest of the day. I’ve got a good vision in my mind, something I can take to work tomorrow.

Ryan Ripley: Agile’s no longer a cancer for you, right?

Zach Bonaker: It never was. I think Erik Meijer clearly, clearly does not believe in Scrum, and that’s fine because Scrum is just a framework, but it’s hard to see how you could call agile a cancer. I guess if you go out there and you see it, and you see how people interpret it, yes, I can say that’s a cancer, but agile itself isn’t. That was a pretty strong statement.

Ryan Ripley: Agile as a word I think is a joke, and I don’t think it’s a funny one anymore. It’s one of those that a lot of people throw it around. I think your article just it hits a nerve with everyone, but it’s a positive nerve. It’s one of those that just acknowledges how silly the words become. I appreciate it on that standpoint. Most people will say, “Oh, we don’t plan anymore. We’re agile.” I’ve heard this on so many conference calls when we’re talking to vendors. They’re like, “No, we’re not going to give you a timeline. We’re agile.”

You try to explain, “Well, wait a minute. I’m just a simple minded Scrum guy, but you still forecast. You still have to forecast a backlog. There’s no … You can actually help us line up milestones and dates.” They say, “Nope, we’re agile. We don’t do that.” That hits into an area where the executives start listening to those kind of calls and they say, “Well, why would we ever do this? Where do we … We lose control. We lose risk mitigation,” and in fact, it’s furthest from the truth. I understand this problem that you’ve pointed out, that Erik Meijer took to an extreme, and that Dave Thomas certainly sensationalized and got a lot of attention around. It’s one that how do we fix it?

Zach Bonaker: Yes, and you know, looking at those base patterns I think is a step. I think we also just, agile or not, we need to look at our organizations. We need to take a very close eye and really try to continuously improve our organizations for our people and for our customers, and in doing so look at what we do and see if that makes sense. Are we doing everything that we can do today to drive the outcomes that we want, which I mean, OK, if it’s software development, it’s software that pretty simply put kicks, that people love it.

It’s great quality, and people are into it. That’s the outcome we’re looking for, so let’s look at the way that we … From top to bottom. Think of our organization as a system. Are we optimizing it? Take a Lean approach to it. I don’t think we do enough of that. It’s amazing to me. When you go in and you look at an organization, you get the salaries. I’ll say, “Hi. Hi, I want the department salaries please,” and “Whoa, whoa, why do you want that?” “I’ll explain it to you, but let me take a look.”

You go and you look at it, and immediately you know there’s a management problem when you can see that there’s one or maybe none, nobody in the department makes more than a manager. OK, what are we doing at this point? We’re incentivizing people to just move up a hierarchy. Does moving up the hierarchy contribute to the outcome that we’re trying to build? Think about software. If I go as an amazing engineer and I just I am a great engineer, and I produce amazing software, and I move up the hierarchy now to manage people, am I helping my organization produce better software?

Maybe. Maybe, or maybe we just, to take the salesman equivalent, maybe we just put the sales person that we had in the sales manager position, and that person can’t manage at all. All they can do is sell. We haven’t really helped our sales. We do a lot of that. We create incentives in our modern western or our western world of corporations. We create incentives that don’t seem to align with the reasons that we’re in business to begin with. You go and you look at an HR department, and you’ll find at some HRs, what’s the metric that they get rewarded on, time to fill?

At a lot of places, it’s time to fill. I think to myself, my God, that means the first person I interview is … We should just … The first applicant I get, boom, make sure that they’re getting an interview. I mean how is that getting the people into the organization to grow the organization and deliver the outcome that we’re looking for? You talk to HR people, and I’ll use one, I’m not going to say who it is because I don’t think that’s fair to the organization or the person, but asked the director of HR at a company about this.

They said it was time to fill. OK, that’s great. “Tell me about what the difference is between hiring a person and filling a position.” They go, “Well, they’re the same thing, and if anything, we have to make sure that we’re filling the position. I mean we can just hire anybody, but we’ve got to make sure that we fill the position right.” That’s so backwards to me.

Ryan Ripley: No, you’ve got to fill the role, Zach. You’ve got to make sure the role is aligned, and filled, and that you check that box off.

Zach Bonaker: Yes, you’ve got to check the box. “Do you have eight years of experience?” “Well, maybe I only have six.” “Well then, you’re not qualified enough.”

It’s crazy to me. When are we going to value hiring a person as a means of solving our problems and growing business, not just filling positions? There’s a whole lot that we could talk about just in business in general. I think agile thinking helps inform a lot of that questioning of what we do, trying to see if there’s a better way, and really I’m just saying the status quo, it’s not good enough. I think we can do better.

Ryan Ripley: The interesting part really is that it, among the many things you mentioned, it forces you to have a goal. One of the most eye opening things I entering the corporate world and then navigating through a career is that not a lot of it’s goal driven necessarily. You have people doing things out of tradition, things out of ceremony, things out of fear, things out of risk mitigation, things that whatever motivation there is, but it’s not goal based other than to avoid pain. That’s what these systems have I think done is that it just makes people look at the rewards versus the behavior expected, follow that pattern, and not really think about what you’re doing.

Zach Bonaker: Yes, you’re right. Have you ever, in your transformations with the people you work with, have you ever heard a lot of criticism around management in agile that like, “Oh, we just need to get rid of managers. We don’t need managers. We’re agile”? Do you get a lot of that?

Ryan Ripley: I have heard a lot of talk of that, and it actually sparked a talk that I’m going to be giving next month out in Vegas at the Better Software Conference. I’m very interested in the idea that a manager still has a place in an agile organization, that we can’t just throw books at them. Management 3.0, for example, excellent book. Drive, by Dan Pink, excellent book. We can’t just throw them at people and say, “Everything you’ve done for the past 20 years that’s made you successful is wrong, and here’s what’s right, and as soon as you get this, we’ll be successful.”

That’s not the approach. That’s a train wreck, but I think there is a way to understand them, as we talked about. I think there’s a way to approach them. Then there’s a way to teach or coach them to be an agile enabler. If we can have those valuable discussions that you were talking about earlier, if we can make that connection, tell them a story that’s true and authentic, and then get that value proposition in front of them, a lot of that other chatter goes away, but you’re right. The teams right now, I think there is an undertone of distrust towards management that we do have to crack at some point.

Zach Bonaker: Yes, yes. I’ll put the host on the spot. Since you’re interested in it and you’re giving a talk, if people ask you and they say, “So, what is the role of management in agile, what is agile management?” How do you respond?

Ryan Ripley: The role of an agile manager, and yes, thanks for putting me on the spot there, Zach, that’s great, yes, the role I think is to, and a lot of people will give the cliché, to enable the team, but I think the role of the manager is to create an environment of success for the team. Instead of assigning people to a team, how can they attract talent? How can they retain talent? How can they put systems in place that keep people where they are currently are with great incentives, and great benefits, and all of those things, and not have them leave? How do they do that? How do they enable a team to deliver continuously? Can they work across organizations?

Can they break down barriers and have influence outside of their org chart? That’s their role now. It’s not to pick out tasks. It’s not to say, “Hey, this is the job you’re going to be doing today,” like a factory worker from the 1960s or 50s or 40s or whenever. Now it’s that person that reaches across boundaries and takes down barriers. That sounds, that’s still too pie in the sky. That’s still too … It’s not very clear. What I see as the day in the life of an agile manager is someone who addresses the needs of the team. Then that definition will be different context to context, work environment to work environment.

Zach Bonaker: Yes, I completely agree with all of that. It’s something that I’ve struggled with too because my answer is always, feels pie in the sky too. I hate it. You talk with business people that have spent 20 years being so process-centric that everything to them is just it’s a solution, it’s a structure. Sometimes we deal in complexity here that there isn’t a clear answer. I think it’s always right to say, “I don’t know. It kind of depends. It could be a little bit of this and a little bit of that.” It sounds so puppies and kittens. I wish we could get a better way of doing it.

I always tell people and I say, “So, what is agile management? What happens to management, especially middle management in an agile transformation?” They say, “Well, they make a pivot.” This isn’t my quote. Unfortunately, I want to say it’s attributed down to Lyssa Adkins or someone, but management works on making a pivot away from ensuring people do things right to guaranteeing that we’re doing the right things. People just go, “What does that mean?”

I go, “Well, think about it. Think about it. We’re not talking about making sure people are doing things right. That’s not your job any longer. You’re making sure that your teams are headed in the right direction, that they’re doing the right things, that they’re taking a value driven approach to their work, that they’re focusing on delivering working software in whatever increment or time period if it’s flow based, that you’re doing the right things, that we pursue these outcomes that we pursue from an agile way of working.”

“Yeah, OK, I kind of get that. It means I do a little bit of this, a little bit …” Yes. Yes, it is, but I agree with everything you say. I like some of the ways that you put it more than mine. It definitely feels fluffy to me but, yes, I think that’s an area too that we grow and experiment. What is an answer that resonates with our modern organizations about what it means to become management in agile?

Ryan Ripley: I think part of it too is making sure that your teams have the skills that they need to deliver successfully. Are they T-shaped? If they’re not, get them trained, but also there still are boundaries that have to be set by a manager. I think the easiest way to explain this, the way that I explain it in my talk, is through the context of Scrum. Scrum is not a perfect framework. It’s not by any means a silver bullet, but I think it is a great on-ramp to agile. It gets you thinking in a way that we’re going to deliver frequently, we’re going to inspect and adapt our practices, we’re going to be transparent, all good things.

If you look at the Scrum framework from the point of view of management, I think there are areas where a manager puts things on the rails. For example, Definition of Done. There are organizational practices and policies that have to be enforced through a Definition of Done that a manager can influence. I think that would be first and foremost, but a lot of the activities then, you have your sprint planning. You go into your sprint backlog. You do your development, your daily Scrums. The manager’s not in there.

He’s not really, or she’s not really interacting too much unless there’s actually an HR related conflict. Then they have to step in, and that’s still a role. You get to where you’re in a sprint review. That’s where I think the manager shines. They’re watching what the team did. They’re listening for verbal cues of how they’re presenting the software, how they’re discussing how the sprint went with the product owner. They’re inspecting the backlog. There’s all these cues that they can pick up and help provide guidance in a very non-threatening way.

They ask for permission to give a suggestion, for example. They’re not invading on the team. They’re guiding and trying to move them in a direction, not force them. Agile retrospectives come up. If there are things that come up in that retrospective that you have to reach across organizations, again, the manager has a role, but mostly he or she is setting up success. It gets back to, like I said, are they T-shaped? If not, get them training. Do they have access to the database people? If not, establish that.

Once they’re working in that way, they can actually focus on developing talent. A colleague of mine, once he went through this transformation, he became an agile manager. We were sitting back one day and he said, “You know, it’s amazing, Ryan, I’m actually for once in the past 15 years, I’m doing my job. I am developing people. I am managing careers for people. I’m helping them grow, and I’m not caught up in the tactical day to day nonsense that I was before. I’m not caught up trying to force a delivery of a project that’s dead on arrival. I’m helping people.” It was really, it was a neat moment. It’s one of those tank fillers that you mentioned where you’re like, “All right. This guy just found his calling. He’s happy with what’s going on.” I think it’s so much more fulfilling than checking a box on some project management method.

Zach Bonaker: I agree. Thinking about all the things that we’ve talked about, the top down to bottom up, the principles of agile as a development standpoint to an organization, and management, you talked about you’ve got a lot of experience with Scrum. When you take all this together, when we’re going to create a Scrum team, when we’re going to get the outcome that we’re really looking for with Scrum, what’s the most important part do you think? What’s the piece that makes it all happen? Is there a key that without this it doesn’t happen? What’s really the big thing in creating a successful Scrum team or Scrum in an organization?

Ryan Ripley: It has to be voluntary. That’s first and foremost to me. That’s got to be most important. Agile by coercion is a failure. I think the people have to be given the choice and make a conscious decision that they want to do Scrum and they want to be agile. What that leads to, I know you wanted the one thing, but that leads people to internalize the agile values and the principles. If that’s driving their thinking because they’ve willfully or voluntarily accepted that, I think the chance of success goes through the roof.

Zach Bonaker: Yes, we can’t just tell somebody. We can’t get the benefits or we can’t achieve the outcome we want by just making people do it without understanding why or feel like a purpose. It’s like when we say collaboration. We want our teams to collaborate. We don’t really get the benefit of collaboration by saying, “OK, now you, go collaborate with each other.” There has to be a reason. I’ve noticed in a lot of, with Scrum especially, it is so well known, and it is so popular.

You get out there with the organizations, and they try it, and they look at the people that they have and they go, “Look at you. You’re a project manager and, let’s see, Scrum has a Scrum master. OK, well, that sounds about right. Here, we’ll make you a Scrum master and business analyst. Yeah, that’s kind of like a product owner, right? OK, now you’re the product owner,” without even really considering the real responsibilities, what the role really is. We’re not just trying to map it to what we have in our existing processes.

It’s a new process. It may require new people. I find that it’s the business analyst, it’s the traditional technical, the real analytical, and the brilliant people. I love them. They fascinate me, because these business analysts are so amazing at taking complex problems and doing a really good job of trying to think of everything that could possibly happen, which just makes my head explode, but these are the people that end up driving backlogs for teams. I find myself constantly spending way too many hours just trying to align flow of information to teams to enable Scrum to even take shape.

I was curious if you had challenges like that as well. To me, it feels like we’ve abuse the word ‘product owner’ in agile way too much. It’s like product owner is an agile thing, and it isn’t. It’s a Scrum thing. If I’m going to use Scrum, I need somebody who is better at creating problems or explaining problems, and motivating, and engaging people to solve them rather than writing user stories. It’s an entirely different person. I’ve found that for me, I say, “Where are all the product owners out there?” If I’m seeing these Scrum shops, where really are they? Because it takes a special type of person to enable that framework to run.

Ryan Ripley: Yes. I’ve actually seen the exact pattern that you laid out, where a very talented BA took over a product backlog, and there is a lot of time and coaching that goes into turning off the analytics from a tester and trying to get them more into sharing information, acting transparently, flowing those stories out to developers, not assigning. Because there’s still that tendency because they want to assign the bug. Now they want to assign the story. I think you’re right. That can be a time sink, but I also share your frustration I think with where have all the product owners gone.

It’s not a new concept. There have been product owners since the first product was created. I mean it’s the care and feeding of your product. It’s interaction with the customer. It’s all those things that traditional business has done since the beginning of time, and it shouldn’t be too terribly different now except for the collaborative aspect of the role. Now you’re implanted. It’s almost like the reporters who get implanted with a military strike force in a foreign country. Now you’re a business person who’s been …

You’re integrated with a software development team, and you are in foreign territory working with them on how to turn your thoughts into their code. That’s a key difference. It’s that customer collaboration over contract negotiation. You know the lost value of the actual manifesto. I think you’re right. It’s a difficult role to fill. It’s one that not many people do it well. To counteract that, whenever I’m dealing with a product owner who’s struggling, I hand them Bob Galen’s book, Scrum Product Ownership, Balancing Value from the Inside Out.

It’s a treasure trove. You can read this book … I’ve gone through it probably five or six times now. It’s full of notes and highlights. Just every time I read it, there’s a new thought about that role. He just, he captures it so well. I think anyone out there that wants to be a product owner who’s struggling being a product owner, that’s a book to pick up and just internalize. The more of Bob Galen’s insights you can pull in, I think the better you’re going to be.

Zach Bonaker: Here’s an interesting little thing I’ve uncovered in the last year. I’m a big believer, again, in people, and I’m really fascinated by the behavioral aspects of different people and how they respond to the Scrum framework or agile thinking. I’ve found that, and I think you’d probably agree with this, most companies that say, “Yeah, yeah, we’re using Scrum” really aren’t. They’re trying, but it’s not really there. A lot of those struggles happen, again, with the idea about the product owner.

I’ve realized that maybe we have the … We’re putting the wrong people in place. Maybe there’s better places for what we’re calling product owners now that we can leverage, but we’re going to need real product owners. I’ve asked people this, “Instead of product owners, what if we just change the word and let’s see how that affects people?” I started calling them product leaders, and I’ve had a couple of cases now where people have said, “So, we’re going to be calling them product leaders?” “Yeah. Yeah, that’s an important change we’re going to make. They’re going to be product leaders now.”

“Oh, well, we’ve got the wrong person then in that place.” It’s like, really? Snap, just like that. I don’t know, it’s something about the owner, because this, like a business analyst was so technically knowledge, and could really own … No, they’re the owner but, no, no, if they need to be a leader, no, no, no, that’s not the right person. I found that to be fascinating, stop using product owner in places where it feels a little abused. We’re getting a little squishy with our use of user stories and product owners, and start calling them product leaders. All of a sudden people started to say, “Oh, well, we should probably readdress who we have in that role then.” Fascinating.

Ryan Ripley: Yes, I think the distinction in words is excellent. A product owner sounds tactical. It’s more of a day to day. The product leader sounds strategic. I want a strategic thinker as a product owner. I want them thinking about future direction of the product, how it interacts or how it impacts the customer’s life, where the value is, where all those things are. I don’t want them thinking about the next acceptance test they’re going to write. That shouldn’t be their core focus. I do agree. I like that distinction a lot, and I may give that a shot the next time I’m having a conversation with someone struggling to assign a product owner. Maybe that’s the drill or maybe that’s the pro tip. If you’re struggling with who to pick out, who would you want to see as a product leader instead of a product owner? If that makes your decision simpler, maybe you need to change the word too. I like it.

Zach Bonaker: Use it. Experiment. We’re going to adaptively experiment for our competitive advantage.

Ryan Ripley: The fun part about joining the agile community is that words matter. I find that when I get around some of the … You get around the thought leaders. I even hate that term. I’m using bad words here. Let’s say you get around some of the more well known agile people. You get around the authors, and the speakers, and all of these big thinkers that we aspire to be someday, and you start using the wrong words. They stop you immediately and call you out. It’s not to be rude, it’s not to be disrespectful. It’s because there’s a meaning behind that word.

This is the first community I’ve seen where, I think in the medical profession words are very important, but in our careers, in our industry, Zach, I think this is an area where, yes, if you use the wrong words in an agile context, you really can cause … It’s almost like an anchoring effect. Product owner, they own the product. They manage the product, so they’re tactical, they’re delivery based. All of a sudden, you go out on this path, but instead product leader anchors that strategic thinker, outward looking, multiple focus. I think it’s just a neat side effect of the community that these words have so much power.

Zach Bonaker: Hit me with your book recommendation. What should I be reading, and I’ll give you mine.

Ryan Ripley: I love this little book. I just picked it up. It’s Jason Little’s Lean Change Management. I’m really enjoying it. I think he’s laid out … These canvasses that he’s using to do organizational change, very powerful. A really interesting way to do it. It’s just an information radiator that I think this is going to be a … This will be powerful stuff.

Zach Bonaker: OK, I’ve got it written down. I’m going to check it out. I just finished, and it’s not a … Everyone’s reading it these days, but I mean Reinventing Organizations is pretty fascinating. If you haven’t started reading Reinventing Organizations by Frederic Laloux, man, that is some amazing stuff. I mean everyone, so listeners know; yes, OK, I’m a little psychological. I like the behavioral side of people, so Reinventing Organizations really explores our development as humans on how we form organizations, but it’s amazing and inspiring to hear some of these organizations that have been created where, wow, that’s agile.

We talked about an agile organization. Wow, that’s it right there. Really cool. Check it out. I’m re-reading right now Joy, Inc. by Richard Sheridan. If you haven’t read Joy, Inc., that’s, readers out there, pick it up. That’s you’re an agile thinker and you want to think, “Huh, how can leadership really enable change and transformation in a beneficial, meaningful way?” There it is, Joy, Inc.; Richard Sheridan.

Ryan Ripley: I think those are three great books for people to pick up, and Bob Galen’s book, to read that one. I think that’s a must read. Even if you’re a Scrum master and you’re not a product owner, that’s a must read, just to understand who you’re interfacing with. Would you agree?

Zach Bonaker: Yes, it’s great, a great piece of work.

Ryan Ripley: There’s four more books for our listeners. Zach, I don’t know if you got a chance to listen to episode one yet, but we’ve probably recommended probably 17 books in three episodes now.

Zach Bonaker: We are a treasure trove of knowledge. We are just broadcasting literature for all to enjoy.

Ryan Ripley: Amazon.com loves the agile community I think. You are right, we have reached our time box. We both have little ones to attend to, so I think we’re going to wrap it up here with just do you have any last thoughts? We’ve had I think an excellent conversation. I really have enjoyed finally getting to speak to you and not just argue with you on LinkedIn.

Zach Bonaker: Yes, because we did argue. I remember our first interaction was quite back and forth about estimating so, yes, interesting start.

Ryan Ripley: You know what? I think what was interesting there is that, we won’t bore everyone with the details, but I think it’s just such a passionate topic, and these LinkedIn conversations are imperfect mediums.

Zach Bonaker: Things get sideways. Things get sideways real fast over messages, yes, agreed.

Ryan Ripley: No, I appreciate that we both reached out, took care of it, and I thought this was great. I hope we get to do this again. The last pro tip … We’ve had a wide ranging conversation, but what do you think if people can just do one thing tomorrow, what should they do?

Zach Bonaker: OK, for the first thing to do tomorrow, go in and look at your self-organizing teams. Take a look and test them to ensure that they’ve got a shared goal that they’re working towards. We talk about self-organization in agile. We’re not doing a strong job at making sure that our teams align with a shared goal, because in the absence of a shared goal, self-organizing teams, they turn to chaos, and bad things start happening. Don’t let the chaos happen. Make sure that we’re creating purpose and goals for our teams.

Ryan Ripley: Strong words to finish on. Zach, thank you so much for joining me. I really appreciate it. If people want to get a hold of you, how can they find you?

Zach Bonaker: You can always connect with me on LinkedIn (https://www.linkedin.com/in/zachbonaker). I use that, and I am finally, finally after years and years of saying I’ll never do it, I’m on Twitter. You can check me out at Twitter at @ZachBonaker. That’s probably going to be the best way. LinkedIn or Twitter, happy to talk with you. I love this stuff. I’ll chat anytime. Hey, I had a blast, Ryan. Let’s do this again.

Ryan Ripley: All right. If you’d like to keep the conversation going, please visit http://agileanswerman.com and leave a comment on the podcast posting, or if you’d like to reach out on iTunes, we’d love to hear your reviews and feedback, five stars, helps us out a lot, and five is our favorite number. If you’d please go to iTunes, leave a review of the podcast, we certainly would appreciate it. You can also hit up @RyanRipley on Twitter, along with all of our other hosts, to leave your comments and feedback. We’d love to hear about the topics that are important to you and how we could make the show better and more valuable for you. Thanks for listening, and have a great night.

Participants

Ryan Ripley has worked on agile teams for the past ten years in development, ScrumMaster, and management roles. He’s worked at various Fortune 1000 companies in the medical device, wholesale, and financial services industries. Ryan lives in Indiana with his wife Kristin and two sons. He blogs at agileanswerman.com where you can read scrum tips, agile practices, and listen to the Agile for Humans podcast. Follow Ryan on Twitter @ryanripley.

Zach Bonaker is a San Diego based agile coach who specializes in bringing lean thinking to organizations and teams over varying sizes across the country. He leverages his skills in “benevolent inquiry” to help transform people, systems, and structures towards safer and faster ways of delivering high quality software. When he isn’t thinking about next-generation agile ideas, Zach can be found enjoying the sunny west coast weather and connecting with people all around the world. Follow Zach on Twitter @zachbonaker.