Episode Description:
In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is going solo. He will be sharing the top 10 misconceptions he regularly runs into related to agile, Scrum and Kanban. Some of these myths include believing that Scrum is a methodology; that agile is a process; and that following the mechanics of Scrum is sufficient enough to be an excellent team. Have you run into any of these? Or do you believe them yourself?
Prepare to have 10 myths debunked. Tune in to hear them all and find out if you’re mistakenly falling for one of these misconceptions.
Key Takeaways
Misconception #1: There is an agile process:
Agility is 4 values and 12 principles.
When The Agile Manifesto was created back in 2001, they defined the various values and principles from what they found was common in finding success; they didn’t just imagine what a new process might be.
Misconception #2: Agile is good and every other approach is bad:
- Agile works really well for complex, challenging problems that require teamwork to deliver a solution.
- Straightforward problems may not require agility; simple problems require simple solutions
Misconception #3: Scrum is a methodology:
- Scrum is a lightweight framework.
Misconception #4: “We do Scrum…but…”:
- If you don’t follow the Scrum Framework, you’re not doing Scrum.
- By saying, “We do Scrum…but…” you’re putting cracks in the Scrum Framework which is going to inhibit your teams’ ability to be successful using the Scrum Framework.
Misconception #5: Following the mechanics of Scrum is sufficient enough to be an excellent team:
- Scrum’s effectiveness is really enhanced when teams embrace and understand the values behind the Scrum Framework (focus, openness, respect, courage and commitment).
- When the values are not present, you can follow the mechanics but you’re really going to be lacking in your ability to become a high-performance team.
- Scrum values really bring the events, the roles and the framework to life.
Misconception #6: You can have a highly productive Scrum team without adopting good engineering practices:
- Though this might be true if you are organizing a group of volunteers to do yardwork for a nonprofit, it doesn’t work for delivering a working increment of software every sprint
- You will be very challenged as a Scrum team if you do not have good engineering practices that are agreed upon as a team
- If you don’t take time to continually practice intentionally growing your engineering skills to share those with the team, that’s going to limit the ability for your Scrum team to be highly productive.
Misconception #7: We can do Scrum without improvement:
- The Retrospective at the end of each Sprint is an opportunity for your team to become intentional about committing themselves to continuous improvement.
- No Scrum team is going to be perfect right out of the gate, but you’ve got to commit to continual improvement.
Misconception #8: Running to Kanban because the Scrum boundaries are uncomfortable:
It’s difficult to put together a product increment every Sprint but these are opportunities for growth and improvement; not your reason to run away and use a different approach.A misconception about Kanban is that it is an iteration-less framework; in reality, Kanban has values and principles just like Scrum.
Misconception #9: You don’t “go to” Kanban:
- You apply Kanban’s values to the work that you’re doing and you embrace those principles (in other words: you just start doing Kanban).
- Do not invent a new workflow that you imagine will work; just start with where you are.
Misconception #10: Scrum and Kanban are mutually exclusive:
- They work incredibly well together, so feel free to use them together.
- You can use the information you glean from Kanban to help improve your teams’ ability to deliver using the Scrum Framework.
Mentioned in this Episode
Transcript
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach, and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to the Agile Coaches’ Corner. I’m your host, Dan Neumann and thank you for joining today. In this episode, you’ll be hearing 10 popular misconceptions that I frequently run into related to agile, Scrum and Kanban. So if you’re wondering what those might be, stick around with me and we’ll go through them briefly. The opinions you’re going to hear today are mine and mine alone, not necessarily those of AgileThought, other folks or other companies.
Dan Neumann: [00:45] The first place I want to start related to misconceptions is that there is an agile process. I don’t know how many times I’ve run into that. When people talk about agile being a process, agility is four values and 12 principles. You can see those four values and principles on the agilemanifesto.org website. When the manifesto was created, it was that the lightweight methods conference back in 2001 and a bunch of folks that had been having success using a bunch of different approaches, different methodologies, different processes, different Frameworks, got together to distill what was common across all those different approaches with which they were having success. So they didn’t get together and just imagine what a new process or a new approach or a new set of values and principles might be. What they did was distill from what was being successful and from that they captured the four values and the 12 principles that are memorialized in the agile manifesto. So there is not an agile process. There are agile values, there are agile principles. If you’re doing something, an activity that aligns with those values and those principles, congratulations, you’re doing a method that would be considered agile. If what you’re doing does not align with the values and the principles in the manifesto, then you’re not. If you’re curious to hear some thoughts from one of the agile manifesto signatories, one of the folks in the room when the agile manifesto was created, go back a few episodes and listen to the recording I did with Arie van Bennekum as we talk about what that experience was like and some of the history of the agile manifesto.
Dan Neumann: [02:29] I found that to be pretty insightful. I learned some new things. It clarified some misunderstandings I had and it was a great time talking with Arie. The second misconception is that agile is good and every other approach is bad. In reality agile works really well for complex challenging problems that require teamwork to deliver a solution to. There are a lot of problems in this world that are pretty straightforward. If you have a bolt that needs to be turned and you have the proper wrench, you don’t need to form a team. You don’t need to do Scrum or apply agile methods to that. You just need to get the wrench and turn the screw in the software. There are equivalents to this wrench turning. There are simple problems for which there is a best practice. Sometimes you can buy the solution to that. You don’t necessarily need to take an agile approach to every challenge that you run into in the software development world. If you’re trying to create a software product that your users will love, agility can help. You work with your customers. You deliver early and often you welcome those changing requirements for competitive advantage and then you tune and adjust your behavior over time and that will lead you to a likely more successful outcome and one that’s different than you might’ve imagined if you were to have written down everything you thought during a requirements gathering process under a traditional approach.
Dan Neumann: [03:54] The third myth I want to talk about is Scrum as a methodology. I hear that a lot that it’s referred to as a methodology. I think a lot of folks come out of a heavier weight methodology where there are lots and lots of prescriptive steps for everything. There’s a specific way to do everything. In reality, Scrum is a very lightweight Framework. There are the roles that are within Scrum, product owner, Scrum Master development team. There are the artifacts, product backlog, sprint backlog and the product increment that you deliver every sprint. And then there are Scrum events. Of course there’s the sprint itself, Sprint Planning, daily Scrum, Sprint review, sprint retrospective, and so you can tell that there’s not a lot there as far as a definition that would apply to a methodology. It’s incredibly lightweight and not a methodology. So refer to Scrum as a Framework and not a methodology and you’ve got the third myth debunked. So given that there’s only a few roles, events and artifacts, one of the things that leads us to myth number four is we can do Scrum but. So often that sounds like, well we do Scrum but we don’t have somebody filling the Scrum Master role or we do Scrum but we don’t have a working increment. At the end of every sprint. We build in one sprint and test in another sprint or we do Scrum, but we don’t do the daily Scrum.
Dan Neumann: [05:30] Scrum is such an incredibly lightweight Framework whose roles, events, artifacts are all self reinforcing. So if you don’t have a Scrum Caster who’s responsible for the Scrum Framework being followed and implemented well and continuously improved upon, if you don’t deliver an increment, how do you remove the risk that you’re building something that your customer doesn’t like or that it simply isn’t going to work. So by putting in that, but in Scrum, but you’ve created these gaps and these cracks in the armor of the Scrum Framework and that’s going to really inhibit your team’s ability to be successful using the Scrum Framework. Now it’s okay to not do Scrum, but really be aware that if you’re doing Scrum but something else, then you are introducing some challenges for your team and something will probably bite you later on. Method number five is that we can follow the mechanics of Scrum and that’s sufficient for being an excellent team.
Dan Neumann: [06:36] Scrum’s effectiveness is really enhanced when teams embrace and understand the values that are behind the Scrum Framework. So the values that are there are focus, openness, respect, courage and commitment. So yes, you could have the Scrum events happening. You could have people who are filling the roles that are defined in Scrum and you could even have the artifacts of Scrum, but perhaps the team is lacking focus. Perhaps they don’t have a clear sprint goal. Maybe they’re not being open about challenges they’re running into. There’s a lack of respect for each other for the Framework. They don’t have the courage to really go after the big hairy challenges that the team has or they’re afraid to commit to delivering a sprint goal and committing themselves to the Framework itself. So when those values aren’t present, you can follow the mechanics all you want, but you’re really going to be lacking in your ability to become a high performance team. So just like the values and the principles of what makes agile are really critical to understanding agility itself. Scrum values really bring the events and the roles and the Framework to life
Dan Neumann: [08:04] The sixth thing that I encounter is that teams think that can be a really highly productive Scrum team without adopting good engineering practices. Now, that might be true if you’re using the Scrum Framework to organize a group of volunteers to do yard work or maintenance at a nonprofit. In fact, back in 2009 one of the first agile conferences I went to, Reverend Arlene Sutherland, the wife of Jeff Sutherland, who’s a unitarian minister, was talking about using the Scrum Framework just for that, for organizing volunteers around work and service that needed to be done related to the church ministry. I thought that was a pretty cool kind of introduction to Scrum and doing something other than software development with it. But if you want to deliver a working increment of software every sprint somewhere between one week and four weeks and you don’t have test automation to make sure that increment works, you’re going to be very challenged as a Scrum team. If you are not employing practices that allow for collective code ownership, you’re going to be bottlenecked on certain individuals doing specific activities on the Scrum team.
Dan Neumann: [09:18] If you don’t have patterns and practices that are agreed upon as a team, as part of a working agreement, you won’t have those rules and those guidelines to fall back on and that will also affect your ability to have collaborative code ownership and if you don’t take time to continually practice intentionally growing your engineering skills to share those with the team or maybe outside of the team across the organization, that’s also going to limit the ability for your Scrum team to be highly productive. So in addition to the Scrum Framework itself, the roles, events and the artifacts really encourage your team or you yourself, if you’re a development team member, get in there, start modeling that behavior. Start looking for opportunities to introduce new practices, to invent your own practices perhaps. That leads me to myth number seven we can do Scrum without improvement. One of the Scrum events is the retrospective. It’s put at the end of every sprint. It’s an opportunity for the team to really become very intentional about inspection and adaptation, committing themselves to continuous improvement. This lines up really well with the 12th principle behind the agile manifesto, which is at regular intervals, the team inspects and adapts and improves their processes. No Scrum team is going to be perfect coming out of the gate. Perfection isn’t even the goal. I hesitate to say that you’re not going to be perfect. There’s no perfect. There’s just continuing to get better and better yet maybe you’re pretty good. Maybe you’re darn good. Maybe you’re excellent, but then the challenge is what’s next? What’s the next opportunity for us to improve as a team? Keep looking for those being curious. You may need to leave the four walls of your organization and go out and see what’s happening through different conferences, different speaking events, engineering opportunities to practice whether you’re giving back through some community activities.
Dan Neumann: [11:24] I think of things like code for America is one of those practices or one of those organizations that really benefits from development skills and going out and practicing. You can meet some really cool people that way, so with Scrum continue to improve. If your retrospectives aren’t being effective, learn how to get better at retrospectives. That might be an area for improvement and retrospectives aren’t the only place where you would really inspect an adapter behavior. It’s okay to do that several times throughout the sprint. You can do it on a daily basis, maybe several times a day. Keep looking for small opportunities to tweak and improve the process.
Dan Neumann: [12:08] The eighth place where I see a challenge is people run to Kanban because the Scrum boundaries are uncomfortable, so what does that look like? Very often it looks like a team getting to the end of the sprint and delivering an increment is challenging. Maybe it’s hard to integrate the code. Maybe there are defects, but there’s a lot of challenges and it’s very difficult to put together a product increment every sprint, but these are your opportunities for improvement, not your reason to run away and use a different approach. One of the misconceptions with Kanban is that it is an iteration list Framework. In reality, Kanban has values and principles. Just like Scrum, just like agile. So in Kanban you start where you are, you visualize your workflow, you limit your work in process so you’re not thrashing and trying to work on too many different things. You measure and manage that flow and then you use continuous improvement. So there’s a theme of continuous improvement that runs through agile is in Scrum and is in Kanban. But you’ll notice that in those values of Kanban, there is nothing in there that says it is devoid of iterations, so none of these principles speak against iterations. In fact, with starting where you are, if you’re a Scrum team and interested in Kanban, you would start where you are. You would visualize the workflow, which is your Scrum workflow. Then you limit work in process, you make policies explicit. I left that out earlier and then you measure and manage flow and continuously improve over time, which brings us right to the ninth myth. You don’t go to Kanban, you apply Kanban’s values to the work that you’re doing and you embrace those principles. In other words, you just start doing Kanban. There’s nowhere to go. You just make your work visible. Perhaps your workflow is as simple as to do, doing and done. That’s an okay place to start if that truly is your workflow, but what you want to do then is have explicit policies about what it means to have something start doing, to move from doing to done and then you’re going to look at your data that you’re going to gather about how work flows through that system and then you’re going to continuously improve over time.
Dan Neumann: [14:41] One of the cautions here is not to invent a new workflow that you imagined will work. Kanban doesn’t say pretend you have a new workflow and create that on the wall. Just to start with where you are and I’m really excited that in probably about a month, we’re going to have a podcast coming up with Daniel Vacanti, and if you are curious about Kanban and metrics and how to measure flow and what it means when you start talking about lead time and cycle time and throughput and how you can use that for continuous learning. I think you’ll be excited to listen to Daniel and I discuss that. Like I said, it’ll probably be a month or maybe a little bit more of schedules hold. Of course we will inspect and adapt based on how things go between now and then.
Dan Neumann: [15:28] The 10th misconception that I want to share with you or 10th myth is that Scrum and Kanban are mutually exclusive. I’d mentioned that we have the Kanban principles start where you are measuring managed flow, limit work in process, make policies explicit. None of those things are going against any of the roles, events, artifacts or values of the Scrum Framework, so by all means, Kanban and Scrum. They go incredibly well together. There’s an episode where Eric Landes and I explore that topic and you can use the information you glean from Kanban to help improve your team’s ability to deliver using the Scrum Framework.
Dan Neumann: [16:16] So I hope some of those things help. Like I said, I run into these 10 myths fairly frequently as an agile coach and I would be curious if you are willing to share myths that you run into are misconceptions about agile, Kanban and Scrum. You can tweet it to us with the #AgileThoughtPodcast or you can email them directly to me at podcast@agilethought.com and I’d be happy to see what you have to share and if you disagree, that’s fine too. We’d love to hear where your disagreements are and maybe we’ll both learn something from each other.
Dan Neumann: [16:52] At the end of the episodes. Usually I ask the person who is participating with me, what book they’ve been reading lately and well, since it’s just me, I’m going to share that I’m really excited about having consumed the book, “Radical Candor,” and I did that just very recently because Christie Erbeck and I are going to be recording a podcast probably in a week or two, so it’ll come out shortly after this one on the topic of radical candor and what that really means for managers and for the teams that they manage and how applying radical candor can really be transformative in the workspace. So I’m really looking forward to that. It was something that I think I misjudged the book by its cover and by the title, and so I’m looking forward to a really deep discussion with Christy Erbeck on that topic very soon, so hopefully you’ll also download that episode. Thank you very much.
Outro: [17:45] this has been the Agile Coaches’ Corner Podcast brought to you by AgileThought, get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
