Episode Description
This week, Dan Neumann, your host, is answering a very common question: Why would an organization use Kanban or Scrum?
In this episode, he explains the benefits of both approaches, describing each of them and identifying which of them is more suitable for an organization.
Key Takeaways
The kind of work an organization is doing will define the methodologies or approaches to take.
Scrum is an excellent framework for organizations that are doing complex work, as it is creating software.
If you are in conditions of uncertainty, you want to deliver value frequently, and de-risk your approach, a Scrum framework is the most applicable.
The Kanban method is more than a board with signs and signals.
The Kansan method is a disciplined approach. It includes making status clear, articulating clear policies, set work in process limits, measuring and manage flow, and then make incremental improvements over time.
Scrum or Kanban: A false choice.
Why Scrum?
It works!
Scrum is clearer than Kanban about rolls, events, and artifacts.
Be cautious, there are people using Scrum immaturely and not to its fullest benefit.
It is much easier to find employees using the titles in the Scrum framework.
How long can your organization maintain focus?
Kanban fits better for organizations that are doing work that is frequently changing priorities.
Scrum looks to support a product goal, and focus is maintained for longer periods (three to four weeks sometimes).
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro [00:03]:
Welcome to agile coaches corner by agile thought the podcast for practitioners and leaders seeking advice to refine the way they work band pave the path to better outcomes. Now here’s your host coach band agile expert. Dan Neumann.
Dan Neumann [00:16]:
Welcome to this episode of the agile coach’s corner podcast. I’m your host, Dan Neumann. And I want to take a moment to appreciate you the listener for joining me today. Thank you very much. Last week, there was an episode that was based on a listener question from a person named Andrew who was curious about some of the techniques for a scrum master, really working with developers to more fully embrace iterative and incremental design approaches. We love our listeners and love when we get questions from them. So I wanna encourage you to please keep sending those. We will do what we can to make sure that they get addressed in a timely fashion. Of course, every once in a while, my inbox gets away from me, but I try to keep that to a minimum. Another place. Sometimes I go to look for some ideas is out on different community groups that scrum masters post questions to.
Dan Neumann [01:12]:
And I stumbled across one today that I thought was pretty interesting and would make for a decent podcast. So here’s hoping the question was, why would your team want to, or have to use Kanban or scrum? And this person clarifies that they’re not looking for the differences between the two, but wondering why an organization would use one versus the other. And I will try my best to answer that question without going into the differences. But I feel like the two situations are really intertwined with each other. Why would you use it has a lot to do with the differences between the two that said, I’ll try my best to honor the request, but it does seem like it’s a little bit of a tall order for me. When I think of the type of work an organization is doing that is going to inform which of the frameworks or methodologies or approaches that people would want to take.
Dan Neumann [02:16]:
I see scrum being an excellent framework for organizations that are doing work that is complex creating software as a complex activity. Our users don’t know exactly what they want before. They actually see some software, the people doing the various parts of the implementation. They don’t know exactly how they’re going to do it before they start. And in other methods, of course, like, uh, more predictive methods waterfall, we would pretended that if we just got the requirements, right, then we could get the design right. Then we could implement. Yeah. You know, the story. So I won’t go into the, the waterfall one. So let’s hang in here on the scrum framework, doing complex software development work is absolutely a great place to use the scrum framework. It fits in really well at the scrum team level. I mean the scrum framework is about the scrum teams and delivering value.
Dan Neumann [03:17]:
It also then has implications for the organization on how to feed those teams, how to change your product development approach so that you are building increments of software, getting them out to market there’s that it stresses a lot of parts of an organization when you all of a sudden start to deliver valuable software, much more frequently and ideally much faster than the organization is used to in the past. So if you are in conditions of uncertainty and you want to deliver value frequently, and de-risk your approach, the scrum framework is a tremendously powerful framework for organizations to go down that path. So now let’s talk about the Kaban method for a little bit. And when I think of the Kaban method, I’m not talking about just putting a board on the wall that says to do doing done and pretending that’s Kaban. It’s great. It’s a board.
Dan Neumann [04:15]:
Uh, if you go to the term Kaban meaning sign or signal. Sure. Yep. You’ve got some signs and some signals on the wall. That’s a great start. But when I think of Kaban, I tend to think of a more disciplined approach, which is kind of the con bond method that hopefully people think of when they hear it. So start where you are, make the process visible, establish clear policies, set, work in process limits, measure, and manage flow, and then make incremental improvement over time. And, and that’s the framework that I’ll use as I’m talking about the Kaban method here.
Dan Neumann [04:55]:
That is a tremendously powerful framework yes. At the team level, but really at all levels in an organization for all types of work that are happening. It’s very common for an organization to be very busy, delivering work, but to not really understand the process or the flow that work goes through and to have crystal clear transparency to what the status is of the work, as it goes through. Let me give you an example. We have any number of status meetings that might happen in most organizations on a weekly or a biweekly basis. People run around and they collect statuses. They put together PowerPoints, word documents, emails, all the various forms of communication. And still, it’s not clear what the status is of work, which things are progressing, which things are blocked, where people are engaged in solutioning, where there are dependencies. And that to me is the magic of embracing Theban method specifically for creating that transparency, Hey, let’s get really clear, but what it means for something to be ready to start, let’s get really clear about what it means for something to be done.
Dan Neumann [06:19]:
How many work items should we have in process at various steps, which work items get treated differently than others. You get into method ideas like class of service, where one type of issue gets perhaps access to the expedite lane. And other types of items have to flow intentionally more slowly through the system. That to me is the power of Kaban. And whether you’re doing complex software where the scrum framework could be applied or not, the Kaban method is great for creating transparency to then putting in place or supporting experiments for how you want to improve the flow of work through that. Now there may be some organizations who are trying to make a decision between Kaban or the scrum framework. And I strongly believe that’s a false choice, especially when you start to look at the power of using the scrum framework at the team level, looking at the pressures, it puts on the rest of the organization and making that transparent through the scrum framework. So as your teams are working to deliver rapidly, what are the systems and processes around it that could be made transparent through the Kaban method? So I hope that’s helpful in giving just a few thoughts around the team level and the work
Narrator [07:49]:
Have a topic you want us to tackle, send an email to podcast agile thought.com or tweet it with a hashtag agile thought podcast.
Dan Neumann [08:00]:
One of the reasons kind of shifting to, to a different approach. One of the reasons I believe scrum has such a, a significant market penetration is a, it works. It’s a great framework for software development. So yes, it works. And it is also much more clear around the things like roles, events, and artifact. It’s almost like a little bit of a recipe book. It’s not too complex to learn and you can train people on. Who’s gonna be the product owner. Who’s going to be the scrum master, the responsibilities of a development team member. You can train people on the different approaches to sprint planning and the daily scrum and sprint review, et cetera. And I think scrum often has a, a, a, I don’t wanna say it and be too negative, but you can check the boxes that we’ve trained people, and we’re doing a thing called the sprint and feel like you’re doing really well with scrum.
Dan Neumann [08:59]:
And I think that’s seductive. The reality of it is there are a lot of people that are using scrum very immaturely or not to its fullest benefit. And so that’s the caution as organizations look to scrum is it’s easy to declare victory with scrum before the actual results are being delivered. So be a little cautious about that. If you are an organization considering the scrum framework, let’s talk about what it takes to grow your company. If you’re using the scrum method, I’m sorry, the scrum framework or the compound method, there you go. Accidentally conflated. The two of them didn’t mean to do that.
Dan Neumann [09:37]:
I popped out to a couple job boards and did a quick search for Kanban. And then I did a search for some of the scrum teams, whether it was scrum, scrum master product owner. What I was finding on a couple boards is there are roughly four times as many posts that involve the word scrum as there are, that involve the term Kanban. So almost 20,000 for Kaban almost 80,000 for the scrum terms. And so as a company is seeking to hire people into a scrum environment. I believe it’s much easier to find people who understand generally what the product owner role is. They are filling the scrum master accountabilities to use the new scrum term guide and not to go back to the older scrum terms. So they’re called accountabilities now, but we’ve got scrum masters and product owners. HR can have position descriptions for product owners and for scrum masters.
Dan Neumann [10:41]:
It’s a little, a little easier to hire those. The method is one where you start where you are. So your organization will have its titles and its roles and its accountabilities. And you can continue to advertise for those, but you, you wouldn’t typically go out and advertise for those accountabilities in a con bond framework, cuz again, con bond just says start where you are. So you’re going to have whatever roles and jobs and et cetera, et cetera that you already had and then you’re going to continuously improve. So I do feel like there’s a, a recruiting advantage if you will, of using this scrum framework because it’s easy to say, I want a scrum master, a product owner, a developer who’s using the scrum framework. Another facet of which method to use would depend on how long your organization can maintain focus. If you are in an organization that is doing work, that is, is frequently changing priorities.
Dan Neumann [11:47]:
And by this, I mean daily, maybe support tickets, uh, making widgets, um, call centers, those, those types of things where you’re working issues to completion every day. Um, small tickets is what I think of, I think combine fits better than the scrum framework with scrum. We’re looking to support a product goal. We have sprint goals. We’re asking teams and organizations, stakeholders in that scrum team to maintain focus for a week, two weeks, three weeks up to a month with the scrum framework. That can definitely be a challenge rightly so, depending on the type of work you’re doing. And so depending on the organization where you were to deploy this combine method or the scrum framework would definitely depend on what type of work you are doing as well. The last thought I want to leave you with when it comes to the combine method and whether an organization would consider it or not, is that the combine method can be applied at many different levels and related to other groups within your organization.
Dan Neumann [12:57]:
So I’ll give you an example. You could have a command at the team level. There’s no organizational blessing that would be required for a team to put up a board, make the process visible, write down the policies that are kind of implicit now. So you’d make those explicit limit your work in process measure, manage flow and experiment. That really shouldn’t take a big organizational change to start that at the team level, where there can be more organizational impact is as you start to get higher and higher in the organization to things like what if you had a portfolio level conman for the organization, what are the different initiatives that are flowing through at the highest level? How might those portfolio level efforts be represented in different programs, programs being multiple teams that contribute towards a particular outcome, how are those programs then relating to the portfolio and then below them, the teams, and how would, let’s say a, a program of work about that involves software delivery relates to a marketing team’s combine.
Dan Neumann [14:11]:
I was at a place that had a marketing team that was using Theban method. They had lots of different shows that they would need to go do in any particular year. Some of them were small regional shows and some of them were large, tremendously large, like the consumer electronics show, super high stakes, lots of preparation, big lead times needed to respond to that. And so you had software development efforts in one part of the organization marrying up with hardware efforts in a different part of the organization, married up and needing to all come together for a consumer electronics show and the transparency and the, the ability to coordinate that can be created with something like the con bond method was tremendously valuable for that organization. So for sure organizations that are making products could benefit from the con bond method as well. I, I found to be much more enlightening than simply running around and collecting status and, and putting together, uh, Gantt charts, if you’re to use the more traditional artifacts for tracking those types of projects. So I hope those reflections on what to consider or why would an organization lean towards the scrum framework or the combine method. Hopefully that’s helpful to, you would love to have the questions continue to come in. So again, thank you for those that have something in the past and an invitation for anybody listening here, go ahead and send us your question and we will do our best to get a response to you. Thank you very much for being a listener very much. Appreciate it. And we will talk again in a week. Thank you.
Outro [16:00]:
This has been the agile coaches corner podcast brought to you by agile thought. The views opinions and information expressed in this podcast are solely those of the host and the guests, and do not necessarily represent those of agile thought. Get the show notes and other helpful tips from this episode and other episodes@agilethought.com slash podcast.
Want to Learn More or Get in Touch?
Share These Tweets!
“If you are in conditions of uncertainty, you want to deliver value frequently, and de-risk your approach, a Scrum framework is the most applicable.” — Dan Neumann
“To those organizations who are struggling to decide whether to use Scrum or Kanban, I strongly believe that is a false choice.” — Dan Neumann
