Scrum Versus Kanban: An Interview with Cory Foy

Cameron Philipp-Edmonds: Can you start us off by telling us a little about yourself? 

Cory Foy: I'm lucky enough to have had the opportunity to have a lot of different experiences in my background. I've been involved with technology since a very young age, but was actually going to go into nursing. I ended up spending eight years as a firefighter/EMT, including spending my last year as the assistant chief of a department.

But during that time, my love of technology never changed. I was featured in a local story about a "virtual firetruck" I built in the mid-1990s, and ended up taking over the web team for a large county government. They were entrenched in traditional command-and-control waterfall, and I brought in a collaborative style that I now know as the set of agile methods.

From there, I bounced back and forth between software development and process/organizational consulting, including working for Microsoft as part of their PFE "Swat Team" supporting .NET. I still do that today—lately I've been coaching a large SAFe program in a regulated industry (which we've been undoing SAFe at) and also building awesome software for clients in Ruby and Objective-C.

Cameron: What led you to the idea of your session?

Cory: My session came about because I often see teams who feel like they have to pick a methodology or framework, and then don't go back and see if it actually fixed what they needed to fix. They instead say, "agile doesn't work here." So I wanted to show people that you can must adapt your process and that by knowing many different concepts, you can find ways to incorporate them in order to achieve agility. 

Cameron: When should an organization look to use Scrum or kanban?

Cory: I'd even extend this question to waterfall, because really our goal shouldn't be to 'implement' a specific method or framework. Instead, our goal should be to use that as a starting point and then ask what are the challenges that we have and how are we solving them. Lately I've been using the analogy of "Ascend, Acclimate," but its important to note that what works for a hill climber doesn't work for climbing Mt. Everest. Instead, you spend time learning what's out there and then try it out. You ascend to a point, and then stop to acclimate yourself—did the pack we choose work? Is it loaded properly? Do I need a more formal strategy to get to the next camp?

These same questions happen in organizations too. Do we have a shared vision we can work towards? Are we in an environment that values collaboration? Do we have control over the contracts our vendors are working under? All these things point to what tools we'll need—tools we can always apply with a mindset of agility.

Cameron: That's a great analogy. I really like the phrase "ascend, acclimate". Now, what type of situation would an organization be better off sticking to either Scrum or kanban rather than utilizing some combination of the two?

Cory: We all need a base camp to start from. If we look to the Dreyfus model, it talks about the need for beginners to have clear steps. So I think choosing one or the other as a start is a good step. I think Scrum works well as a starting place when you have a cross-functional team who can see clear increments of work, and have the capability of delivering on a regular basis. I think kanban is a better start when you have varied steps in the process, or when you are integrating with teams.

I say this because of the idea of "work in process." Scrum wants an ending—that's how a team gets velocity. But if a team hands off the work to a testing team, and then a business validation team, and then a deploy team, and then it is scheduled to a release then that work is "in process" that entire time, and we should really use a method which let's us track while we work to make the business case for change.

Cameron: You mention that a team can combine the best of both Scrum and kanban. Is the "best" of both of these subjective, and more of a case-by-case basis, or do they have qualities that are intrinsically desirable?

Cory: Ah, "Best Practices"! Everyone wants a formula to be able to apply. But real organizational change is about experimentation. So I think that inside of those methods are patterns which resolve certain forces and that's where organizations need to get to. What are the real concerns we have? How can we use the patterns in these methods to solve them?

For example, Scrum has the notion of a "sprint," while kanban is more of a continuous flow. However, people like routine, so we bring in the idea of a "cadence." If you are doing Scrum, that's implicit in your sprint length. But in kanban, we can define that to what works—demonstrating whatever is in the done column. So, in effect, we're getting the best of both worlds. I talk a little bit about this in my article "Recreating Scrum with Kanban."

Cameron: Why do so many organizations struggle to adopt empirical views of their process without falling into chaos? How can organizations avoid reverting back to old habits when they are up against the wall?

Cory: It's muscle memory. My dear friend Corey Haines talks about how, when his back is against the wall and he needs to get things done quickly, he reverts to test-driven development. We have a tendency to want to jump in and get control of situations. If we're not spending time practicing the good and the bad, we will revert right back.

For example, as firefighters we spent lots of training on staying out of trouble—proper techniques, buddy systems, etc. But then we spent a similar amount of time on actually getting out of trouble—wild-hose drills, blackout situations, rapid escape down ladders, etc. You are building your capability for agility and that means knowing how to respond.

The biggest question I would ask—if one of the tenants of agility is visibility—how did we get surprised and now have our backs up against the wall? Those are the cases where retrospectives really come in to play, and where real growth can happen.

Cameron: That's a really good question that I think people should ask more often. Now, what takeaways would you like the attendees to leave with after your presentation?

Cory: That they own their process. As an industry, we talk a lot about "Scrum Buts" or people using agile badly. But we are supposed to inspect and adapt. We shouldn't be trying to get to "The Methodology" for our organization but instead, we should be constantly looking at what works and what doesn't. As we find things that work, we should capture those so we have a baseline of our current understanding. Toyota never had "The Toyota Way," they had "The October 2014 Toyota Way" as an understanding that it will get stale, and needs to be revisited.

Cameron: You speak and consult on various topics with one of them being Innovation Games. Why don't more companies consider Innovation Games?

Cory: I think in general, companies struggle with the vulnerability of really getting out and asking their customers questions. Organizations tend to optimize for executing their current business plan—really digging deep may reveal directions drastically different than where the company is headed. We saw that in the camera industry, and I think we're seeing that somewhat with Microsoft. There's a big change happening, and it requires real innovative thinking to dig to find out the things you don't know you don't know.

Cameron: You're also the CTO of a start up, Pretty Kool Apps. Can you briefly tell us a about what that is and how you got involved?

Cory: I'm actually one of the co-founders. We recognized a need for therapists who work with children that needed a suite of apps that didn't attempt to constantly show shiny things, offer badges, etc. Our first app was designed to teach kids how to say "yes" and "no."  That is something that may seem basic, but many speech-language therapists have to work with children on it.

An interesting tidbit is that a large amount of time time in building the app isn't actually in the coding, but it framing and taking all of the pictures. A lot of thought has to go in to what the user will see in it. For example, if we ask "is this a pizza?" but show a slice of pizza, should they answer yes, or no? After all, it's not actually a pizza, because it's just a slice. 

Cameron: That's awesome. You really have to cover all the angles for the user and even get a little philosophical. Now, you've spent the past few years helping organizations increase their agility through various agile and lean principles. But you also incorporate Serious Play. Why should organizations consider Serious Play?

Cory: The most impactful sessions I've had with clients around the globe are when we get hands on and do things. I think Serious Play gets teams and customers into a different mindset, a mindset of vulnerability and exploration. For example, every time I do a "My Worst Nightmare" game about an organization's process, there is always a giant picture of a scary-looking project manager towering over the teams with a checklist and implement of destruction. We wouldn't get that out of a survey.

I do find it interesting that so many organizations give speeches about "thinking outside the box" and then attempt to glean insights from surveys and questions they created. Serious Play is about really engaging to find answers you wouldn't have known to look for.

Cameron: Is there anything you'd like to say to the delegates of the Agile Development Conference before they attend the conference and, of course, before they attend your presentation?

Cory: Your goal should never be to "be agile." It should be focused on delivering and realizing business value sooner. That requires thinking about what value you deliver, how that fits into a value stream, and who your customer really is. If you are new to the agile world, don't get caught up in trying to implement a specific method. Instead, learn about many things—agile, lean and even waterfall—and think about the cases for each. You'll end up with a better adoption.

Cory Foy is a passionate technical leader and coach with more than fifteen years of experience managing and leading teams worldwide. Cory has been most active as a member of the agile software community, consulting and speaking on topics such as Innovation Games, Extreme Programming, Scrum, kanban, and software craftsmanship. He has spent the past several years helping clients increase organizational agility and think differently about their work through a combination of lean and agile principles coupled with Serious Play. The CTO of Pretty Kool Apps, an education startup, Cory currently coaches, consults, and trains for a variety of clients.