The Stack Overflow Podcast

We hate Scrum and Agile too...when it's done wrong

Episode Summary

Well, we don’t hate it per se. It’s more of a love/hate relationship, if we’re honest with ourselves. You can do it wrong: excessive top-down structure is the kryptonite of developer brilliance. Or you can do it right: setting up the team so everyone feels empowered and blameless accountability lets you evolve from mistakes and improve over time. For today’s podcast episode, we sat down with two of our public platform teammates: Jon Chan, Director of Engineering, and Shanda Woods, Certified Scrum Professional extraordinaire, who also happens to be a yoga instructor and cycling coach. We discuss how to embrace Agile and Scrum as a creativity-driving mindset rather than a system of micromanagement.

Episode Notes

About three years ago, when our public platform engineering team at Stack started growing, we realized that we needed a more robust formal project management system that could scale with all the creativity coming on board. That’s when we started looking at formal, by-the-book frameworks to empower and coach our teams to their fullest potential. We landed on Agile and Scrum. 

Admittedly, our development team was nervous about implementing Scrum and Agile at first. So we focused on the goals of introspection and accountability rather than the rigidness of enforcement.

Agile and Scrum get a lot of hate. But is that their fault or are you doing it wrong?

We talked about this on the podcast a few years ago, when Ben, Paul, and Sara wondered, “Is Scrum making you a worse engineer?” 

It’s about providing support—not punishing people. Done right, Agile and Scrum can be a force of freedom and autonomy when they start with trust.

Connect with Shanda and Jon on LinkedIn.

We conclude with a big high five to Lifeboat badge winner jminkler for their answer to how to create an Instagram share link in PHP (thank you).

‘Til next time.

Episode Transcription

[intro music plays]

Ben Popper Does cloud complexity have you frustrated? Well, you can solve issues faster and make sense of the most complicated environments including hybrid, private cloud, and multi-cloud with Splunk Observability. Learn more and get a free trial at Check out that link and let them know we sent you. 

BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am your host, Ben Popper, Director of Content here at Stack Overflow, joined as I often am by my colleague and collaborator, Ryan Donovan. Hi, Ryan. 

Ryan Donovan Hey, Ben. How’re you doing today? 

BP I'm doing well. You are the editor of our blog so I know you're going to be very excited. We have a great clickbait title for today's episode: “Why we here at Stack Overflow hate Scrum and Agile.” This is going to be a barnstormer. I can already feel the comments flowing in. And we have two great guests joining us today to chat about this topic, Shanda Woods and Jon Chan. Hi to both of you.

Jon Chan Hey folks, Jon Chan here. I think you have probably seen me around or at least heard me on the podcast a few times. But for those of you that don't know me, I'm the Director of Engineering for our Community Products Team, primarily responsible for the public platform which is really the Q&A site that I think most folks know Stack Overflow for. So yeah, I’m really excited to have this conversation with Shanda. So Shanda, if you want to introduce yourself here, too. 

Shanda Woods Thank you. I'm Shanda, and I also work on our public platform teams and I spend most of my time helping coach everybody to the greatness that I know all of our engineers are capable of. But no, I work as our Scrum Lead here. You might hear the term ‘Scrum Lead’ from Stack Overflow, but it's essentially the same thing as a Scrum Master in our Scrum and Agile terms, just our thought leaders are choosing to use the word ‘lead’ here.

BP Thought leadership all around. So Shanda, I want you to kick us off because you came to us with the idea for this topic. What is it about the words ‘Scrum’ and ‘Agile’ in air quotes here that you don't like, and what are the ways that you do apply these words or these practices at Stack Overflow? 

SW Sure, maybe this will help with a bit of background for how I got into Scrum leadership. I went through a coding bootcamp and it was really fun, really hard, and ended up writing a bit of React after that and was working at an ed-tech place in Wyoming, hence moving from Brooklyn, New York, all the way to Colorado, which was a fun, physical journey in and of itself. And when I arrived there was this moment of, “I like doing this, but it's not my jam,” and thinking about how I could use skills that I have that were transferable, in a way. Because I was a yoga teacher, cycling coach, all these things for many, many years and did not really realize that we have those types of things in technology as well until I started kind of speaking to the ed-tech CEO and he was like, “Oh, well have you thought of project management?” I was like, “I don't even know what that is. Sure, why not,” and did some research on that type of thing. We went through a little bit of a transition at that place where we had people that were executive leadership or upper leadership that kind of worked in scenarios that were more I'll say waterfall-y, like design studios and things like that. And so with our apprentices, they had to kind of set up the structure to be the same. And walking through that and what they expected me to do in that way was super micromanaging. It was making sure everyone's doing their stuff with an iron fist type of ordeal and just really being hovery and it was not for me. I did not enjoy it. I was like, “Wait, you want me to make sure that everyone's doing their thing at all minutes and all hours of the day? That's not good.” So we researched a little bit about, “Okay, is there anything else that's akin to project management?” There has to be some kind of structure that provides guidance and leadership without being really command and control-ish, and that's how I found Scrum. And taking my first Scrum master certification was like, “Oh, yes. This is it. I want to help people. I want to empower people. I want to coach people and let the people that are best at what they do, do what they do.” And I think there's a lot of people that don't employ that but call themselves Scrum masters or Agile coaches or what have you. I think that there's a lot of that misconception that it's still very command and control and prescriptive when it comes to Scrum, and I think that that's the biggest thing that I like to do– is change people's minds that it's not really supposed to be that way. It's supposed to be more about empowerment and coaching.

BP Jon, have you had experiences with this at Stack Overflow or at previous roles and felt like there were things you liked and didn't like about it or ways we do it differently than other organizations you've been with?

JC Yeah, absolutely. My own personal journey when it comes to learning about Agile and also taking my own teams here at Stack Overflow through an Agile transformation has been certainly a winding road to the path that I'm currently on right now, a lot with Shanda's help here actually. But when it comes to my own previous experience, really it's largely been with what I've had here at Stack Overflow. I joined Stack Overflow as an entry level developer almost nine years ago at this point. And for most of the time that we've been here we didn't really follow Agile principles or a Scrum framework in particular. It was largely about what do engineers really find particularly interesting, and thus being Stack Overflow, we felt like we understood what those problems were and so we just did a lot of those things. And when we were a much smaller team we felt like we didn't really necessarily need something like a really large framework or something nearly as prescriptive as we thought Scrum and Agile were. And it wasn't until we started growing I'd say about two or three years ago that we really started looking at Agile and Scrum more by the book and much more seriously. And I think that it's probably not so surprising that a lot of developers have had some bad experiences with Agile and with Scrum, which is probably why it gets such a bad rap within our industry. But I think it speaks to exactly what Shanda has been talking about which is that when Scrum and Agile is used as sort of an operational framework where it's like, “We're here to track how much velocity that you have and whether or not you're going to be meeting a particular commitment, or making sure that you're all going to be productive so we're going to be measuring as many things as we possibly can,” that's when things really go sideways and that was when, at least when I was first encountering it, I was really afraid of that actually happening on my teams. And it's been really interesting, and again with Shanda's help, that so many of the things that happen when Scrum and Agile are followed the way that it was designed to be followed, it actually ends up having a lot of overlap with the ways that I think about how I want an engineering team to be working from a cultural perspective. It's less about, “Oh, are we putting everybody under a microscope and making sure that everybody is writing a certain number of lines of code,” or something else like that, and it's a lot more about, “Well, how do you want to self-organize? Who do you think that actually has the best ideas here? How do we empower them to make those decisions? How do we make sure that people can be as creative as possible within this framework while still being predictable and working sustainably over time?” All of those things are values that I think constantly about when I think about the culture of my engineering teams and actually I lean a lot on Scrum and the Agile framework to make sure that those things are possible on my teams. 

RD I think anytime we've done any sort of Agile content, anytime we even mention Agile on the blog, we get all this hate about it. And I think it's like you said, when they do it badly it adds this overhead, so I assume that you guys are doing it well. How are we doing Agile at Stack Overflow?

SW I would like to think that there's of course always constant improvement in parts of the Scrum process and just empiricism in general is transparency. You have to be real with what you’ve got going on. You have to inspect that with an openness and courage and sometimes vulnerability, and then you have to adapt. And I think that in those pillars, sometimes if the transparency's not there you're not going to be able to inspect it fully. And if you don't actually put forth action based on that inspection you're going to miss the mark too. So I feel like we're pretty solid at those things where we get to see what is going on, what we're doing well, what we're not doing so well in in that sense of transparency and inspection, and that we're putting forth things in which we can adapt to– and not too fast, but I think fast enough as we want to grow and to progress. So I feel like the pieces of what we do at least for our public platform team is more mindset versus prescriptive framework or things where even getting here and telling people, “What do you want to do? We can decide that?” Yeah, absolutely. And I think that that's the biggest piece that sometimes with Agile implementations or Scrum or whatever framework organizations are trying to instill, is they miss that self-managed, self-organized, let the teams make the decision and figure out how they best work. So I feel like we do that pretty well here. 

JC Just to add to what Shanda has been saying, I think that we're doing it well but of course we could always be much better. Over time I think that's part of the entire mindset, as Shanda put it. To put it into concrete terms, I remember the first time that we were first exploring how to adopt Agile and Scrum in particular. I think one of the very first things that people were really concerned about was just “Well, what happens if we end up not making all the different commitments that we put ourselves to when we started the beginning of the sprint?” At the beginning of every two-week sprint that we have we say that we take on a certain number of tickets or things that we're going to be committing to by the end of the two weeks, and what happens if we actually miss or have one of those things carry over? And the first things that go off in people's heads are, “Oh gosh, if I miss a particular commitment or something else like that, Jon's going to come down and wave his finger at us and tell us that we're doing a bad job or something like that.” And I think again, that comes from this notion that Scrum is sometimes abused or not used in the right way to be an accountability tool, but really what we want it for instead is, as Shanda put it, a way to introspect. It's a really interesting tool to say, “Hey, we might be taking on too much here when we're talking about how to start a sprint off, or maybe there's something wrong with the way that we're communicating with each other that isn't making us as efficient as we'd like so that we're not hitting the mark that we expected.” And it's very rare if ever that I step into this and be like, “Hey, we keep missing our commitments over and over again. I need you to do X, Y, and Z. And this person is not doing A, and this person is not doing B.” It's much more of, “Well, if something's going on here, what do all of you think we should be doing to make this change so that all of you can perform at the way that you're expecting yourselves to perform.” Not so much of what it is that I'm really doing.

BP What about the type of person who comes in and is really looking for direction and wants to be handed tasks? Shanda, you were sort of saying people come in and you say, “What would you like to work on,” and it surprises some people. But what about people who just want assignments and deadlines and that's just their mode of working? How do they fit into this equation? 

SW I think we've also done a good job at that where we know that a team is made up of individuals. The individuality shouldn't be sacrificed in order to create a team. But we also have team commitment. I love this question because I've come across it occasionally where if the whole team decides everything stays unassigned and they just want to pick up whatever, then that's a team decision. If an individual requires something different, we still should have the space and autonomy to be able to address that. And definitely on my teams we do, because I've had that happen before. People are like, “No, just tell me what and I'll do it.” But we work within what we've established as a team. I mean, it seems so simple but not easy to understand that the baseline of all this is communication and how do you work together as a team in order to get to the point, get to the finish line if you will. I think there's a lot of room in there for individuals to have what they want, but at the same time still contribute and work together as a team. 

BP Yeah. I've also heard the phrase at Stack Overflow ‘blameless accountability’, which going back to what Jon said before is like, “Let's talk about this as a team. Why are we missing these deadlines? What can we do better to help?” That's an instance where somebody might say, “Well, it's because X, Y, Z person,” or, “Because when we tried to do this it fell through.” But if you can foster a culture where people feel safe to do that and to figure out how to receive that feedback and then go forward, that's a really powerful thing. In my mind as a manager of a very small group of people, a very scary thing. I'm not sure if I've ever successfully done that, I’d have to let Ryan speak to it. But to get tough criticism in front of all of your peers and then to reflect on that and to build a better system, it’s amazing when you can achieve it. A little bit terrifying at least for me personally to think about trying to institute. 

SW Yeah, that's part of our retrospectives. And this really fundamental piece of the Scrum equation is to have that moment where we do get to inspect these things with transparency, with courage, with openness, and then establish that sense of trust and stability that we can all look at these things, whether it's individual or whether it's as a team, and then instead of it being, ‘this is a failure’, or ‘this is bad’, or all these other negative things that get wrapped up into it, but more of a, ‘this is a learning moment’, or ‘this is a growing moment’, and wrapping it that way where it's not necessarily toxic positivity where you're like, “Yay, you did everything the best,” and that's not true. But really just being honest and understanding that at the end of the day it's not that big of a deal. If we miss a thing, that's totally okay. If something happens, that's fine as long as we look at it and as long as we adjust and as long as we continue to move forward. I think those are the biggest pieces.

RD This sort of seems to fit in the broader trends of management in software engineering in that metrics and these organizational frameworks were used as kind of stopwatches before to be like, “How fast are you going? How can we do better? Let's beat our record.” And now it's more of a thermometer to be like, “What's our temperature? Are we good? Do we need an ice pack? Do we need a little heat?” And I think that's overall positive, but I'm curious. When somebody is not performing or there are performance issues, how do frameworks like these help out? 

JC Yeah. I can speak to this a little bit more because I lean on Scrum and Agile as a really useful tool to really just get a better understanding of what might be happening on the team in the exact same way that the team uses, “Hey, we might be carrying things over,” or, “We’re seeing our velocity go up and down really quite a lot.” I use it as an interesting tool to see who might actually need more support on the team, or who is it that might need something changed about our process to accommodate some of the needs that they may have that's a bit more unique. And Shanda, you spoke to this a little bit earlier about individual needs too, that's where I sort of step in for some of this as well. In the past, I think that some of the folks are really afraid of Scrum and Agile because of the old ways of thinking about how it should be used where it's like, “Someone keeps missing something”, “Oh, once you get your third carried over sprint, that's the third strike and now we have to have a really tough conversation about X, Y, and Z.” But having a different approach about that where if somebody is missing something over and over again and it's something that the team can't figure out on their own, that's when I want to step in and provide some additional support here. For example, we have a distributed team. Maybe somebody isn't great at sprint planning because it is 7:30 in the morning for them and they need to jump right into thinking about how they're going to plan for their two weeks. That might not be something that they can change or adapt to within the Scrum framework. That's maybe a conversation I need to have with them about what their working hours are like so that they can have a better time being prepared for their sprint planning. So again, what I'm hoping is that the Scrum framework and the Agile framework isn't used as a hammer hanging over people's heads, but a really useful mirror for the team first of all, to make changes and adapt so that they can perform it the way that they expect that they should, but also it's a useful tool for me to step in and say, “Hey, who actually might need more support?” And if for some reason we're not able to provide that, find some other way of making sure that the team is going to be performing the way that they expect to and also that that person's going to be as successful as they can be.

BP Shanda, Jon, anything else you want to touch on? 

JC Yeah. For me, the big thing that I want to leave everyone with is that I've had a really winding journey when it comes to thinking about how Agile and Scrum are important to me. But especially as somebody who's leading engineering teams, I really look to these principles and the ways that I'm partnering with Shanda as really pushing the culture or the kind of values that I really care a lot about on the team. I'm hoping that the days are behind us where Scrum and Agile are used as this sort of punishing framework or a way of micromanaging folks. And when we talk about the values around Agile and Scrum around transparency, feedback, being able to be more autonomous and to be self-organizing, those are all things that I talk to all of my engineers about even outside of a Scrum and Agile framework and so I really look to a lot of what's been done here and the work that Shanda has been doing with the teams that are under our leadership as a really critical part of the way that folks actually work here and really enjoy the time that they spend here too. 

BP Awesome. And Shanda, how about you? Any closing thoughts on how this has been going and where you might evolve it? You've been with Stack Overflow for how long now? 

SW Seven months, I believe. It feels like it's a lot longer but lots of stuff has happened. It's that beautiful sense of time though where it's not forever but it seems like a blink of an eye. The biggest takeaway for me is that it's always a gut or an intuitive thing when I think about Scrum and how it's implemented or how other people might implement it. If it doesn't feel like you're working as a team, if it doesn't feel like you have freedom and autonomy to do what you need as a team, then those things should be questioned. Because that's the whole purpose of Scrum. It's a lightweight, easy framework that delivers value and allows people to cohesively do their work. If at any point in time Scrum becomes heavy, and we're not talking about structure. There's a difference between heaviness and then structure where you have certain events that are set up, you have your daily Scrum so you can check in, you have your sprint planning so that you can see what you are capable of in our sprint time, you have our review where that benefits everybody and we get to see the value that everybody's actually working on and delivered, and then we have our retrospective which is something that is the important piece of that transparency so that we can adapt and evolve. And if those things ever feel too prescriptive or too heavy or too anything, then you have to start to question. It should be the way that we do work, not in addition to work. And if that ever starts to become very heavy I think that it's a moment to reevaluate. And also know it's supposed to be simple. It's not easy, because we know that easy things do not equal simple things, but it is supposed to be a simple implementation of something to make people work better. So maybe it's not so evil. 

BP I like that. You're sort of saying it's the structure that should flex to the outcomes and not the other way around, so I like that.

SW Absolutely. 

[music plays]

BP All right, everybody. Well thank you so much for listening. As always, we want to shout out someone from the community who came on Stack Overflow, saved some knowledge from the dustbin of history and was awarded a lifeboat badge. Awarded six hours ago to jminkler, “How can I create an Instagram share link in PHP?” PHP– language of the gods. All right, everybody. If you want to make an Instagram share link in PHP, we have the answer for you. And thanks to jminkler for coming on Stack Overflow, sharing some knowledge and winning a lifeboat badge. I am Ben Popper, I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us with questions or suggestions, If you like the show, leave us a rating or a review. And if you're in the US or Canada and you are a CS student in school, you can check out our Student Ambassador Program which kicked off last week. I'm working on that and would love for you to apply.

RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find all of our latest articles at And if you want to find me on social media, you can find me on Twitter @RThorDonovan. 

JC I'm Jon Chan, I'm the Director of Engineering for the Community Products Team, specifically for our public platform. And you can find me on all socials @JonHMChan.

SW And I'm Shanda Woods, Scrum Lead for our Public Platform Team at Stack Overflow. You can find me on LinkedIn or on Instagram. I have a Twitter but I'm really bad at using it so that'll go into the void if you reach out to me there. Thank you. 

BP All right. I love the Twitter void, it’s my favorite place to hang out. All right, everybody. Thanks as always for listening, and we will talk to you soon.

[outro music plays]