In the early days, there were particular ways of planning, ways of running a retrospective, engineering practices that seemed essential all the time. Now, I make a distinction between a minimal core that I would use all the time, whenever I have a team that’s collaborating to build a thing, and all these other things that may be useful to pull from. I may pull from them 90% of the time, but they’re not Scrum.
In this special episode, Peter and Richard have a conversation with a long-time listener, client, and community member about how their thinking on Scrum has (and hasn’t) changed over the years.
Learn More
Certified ScrumMaster Workshop (virtual, instructor-led)
Certified Scrum Product Owner Workshop (virtual, instructor-led)
Advanced Certified Scrum Product Owner Program (virtual, instructor-led)
Agile & Scrum Crash Course (online, self-guided)
Contact Us
We’d love to hear from you! Tell us what you’ve found useful on the show. Tell us what you’d like to hear us talk about more. Maybe share a challenge you’re facing in your work that would benefit from a Humanizing Work Show perspective. Shoot us a quick email at mailbag@humanizingwork.com.
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work mailbag, where we answer questions from the humanizing work community.
Peter Green
In this episode, we’re talking about Scrum and how our thinking on it has changed over the years. Now, even if you don’t use Scrum, you may find this topic interesting because it’s really about how our thinking on complexity, collaboration, team structure and other things around Scrum have changed. But we’ll get to all of that in a moment. Before we do, we want to help you with whatever challenges are most frustrating you right now.
If you’re feeling stuck on something, whether that’s trying to take a more human centric approach to your work, trying to make your product or business outcomes better, or if you’ve just got a more tactical process related question, let us know about it. Send us an email at mailbag@humanizingwork.com with a few details about the situation, and we’ll share how we might think through your challenge right here on the Humanizing Work Show.
Richard
And just a quick reminder to please rate and review the humanizing work show in your podcast app. Or if you’re watching on YouTube, please subscribe, like and share today’s episode if you find it valuable to you. That really helps us get the word out about the show to people who’d benefit from it.
Peter
Want to get more access to free content we produce, not just the show? Sign up for our newsletter where we share one key idea every week. You can sign up at humanizingwork.com/hwnews or on the footer of any page at humanizingwork.com.
Richard
All right. Onto this week’s topic. This week’s question is from Michael, a longtime humanizing work client, community member and podcast listener. I think we first met in 2011 when I did some coaching with one of his teams. But we’re switching things up a bit this week instead of just answering Michael’s question on the show like we normally do, we have asked him to join us to have a conversation with us about it. So, Michael, welcome to the Humanizing Work Show.
Michael O’Neil
Thank you, Richard. Thank you, Peter. I’m curious– we’ve traveled a number of years together, and I’ve never asked you this directly, but I’ve got bits and pieces of this in different contexts– and I’d like to hear, “How has your thinking about Scrum or its application changed over the years?”
Richard
I’m not sure we’ve ever answered that in one place before.
Peter
It’s a challenging one because it’s hard to remember what you used to think. It’s easy to remember what you think now, and it’s easy to imagine what you used to think. But when I think about what I thought Scrum was when we adopted it, and especially as we started using it, I thought of Scrum as like, “Oh! This is the silver bullet. This is the thing that helps software product teams do better work and learn faster and be less wasteful.” And as I started teaching it, I started to have this experience where I realized, “Why isn’t everybody else getting it?” And the thing I actually realized was that our team had a lot of things going for it outside of and around the team that made it so that Scrum was really successful for us. And so, one of the things I’ve changed my thinking on about Scrum is that, well, everybody should be able to just do this. We did it. It worked for us. Why isn’t it working for these other teams? and starting to focus a lot more on the context around Scrum as being at least as important to learning how to do Scrum.
Richard
So Peter, maybe say more about that. What about the context around Scrum have you found particularly important?
Peter
Well, I’ll relate this back to what was true on our team or that we were able to make true without too much of a challenge. One of the things that was true about our team is that we were already pretty cross-functional. We had software engineering, we had development, we had user experience, we had program management, product management, engineering management, QA management.
All of those were sort of already considered part of the team. And so, when we adopted Scrum, we had the capability to contain any complex thing within the team boundary and that seems to be, I would say, almost a precursor to getting a lot of benefit out of Scrum. We’ve seen teams get some sort of marginal benefits, even if they’re not structured that way.
But without that, you’re really doing a piece of a complex thing and then all of the cool tricks of Scrum don’t work nearly as well. And then I think the other thing that’s sort of related to that is we had a certain level of flying under the radar as far as our group was concerned. We were an audio product in a video group and it was sort of the least important product.
We sort of sometimes felt that way. We used to joke about being the stepchild of this group, like “Ya, OK– the Audition team’s over there” or whatever. But we weren’t making the most money of any of the products. And I think we had built a little bit of trust over the years that that that team is already doing good work.
So we had a certain level of autonomy in how we worked as long as we delivered on the big project boundaries. We had a lot of autonomy to work how we wanted to work.
Michael
Does that, Peter, does that change or inform your thinking around Scrum today, especially when you coach other organizations where people might care more about the team than your experience that seemed to give you autonomy?
Peter
For sure.
It certainly causes me to say, Well, it caused me to say no sometimes when somebody asks, “Hey, could you come in and help this team adopt Scrum?” If I see that they’re really not set up to be successful with it, then I’ll push back and say we could, but here’s why it won’t work well. If we were able to address these other things first, then Scrum will work better here.
And then it really depends on if for that particular organization, whether there’s an appetite for that, whether they agree with that assessment. There’s a lot of other variables there at play, but that’s usually where I start now. I usually don’t start with Scrum as you start to say, do we have the ground conditions that are likely to make Scrum useful for whatever team they want to adopt it?
Richard
I think related to that, one of the things that has changed in my own thinking is the distinction between Scrum itself and the things in and around Scrum that make it work for particular contexts. Early on I had a few contexts that I was able to shape a lot and I started on the XP side of things.
So there were more practices and more to it when you started with a new team and I think back to the first several years I was doing this and then helping other teams adopt Scrum and the whole package that came in as Scrum was a lot bigger. There were particular ways of planning, ways of running a retrospective, engineering practices that seemed essential all the time, and even things like I find user stories really useful, and obviously I’ve written and spoken about those a lot, and I’m much clearer now about how those are a thing you could pull into Scrum, but they’re not part of Scrum. And so that distinction between this minimal core that I would use all the time, whenever I have a team that’s collaborating to build a thing and all these other things that may be useful to pull from– and a lot of them I may pull from 90% of the time– but they’re not Scrum.
Michael
Richard, It strikes me a key piece of your professional organization or I’m sorry, your professional identity, your organization’s professional identity is not about Scrum, it’s about humanizing work. And that’s your company name now. I’m curious about that intersection over the years. Why has that remained constant, even as your thinking may have evolved and changed in profound or nuanced ways over the years?
Richard
The very thing that attracted me to extreme programing back in 1999 and then to Scrum and other things later as the Agile movement became a thing, was that this seemed like a more human compatible way of working. At the end of the dot com boom back there, there were still lots of these big plans and you’d execute for months or years and then test and realize you built the wrong thing and slog through finishing it.
And that just didn’t seem like it fit humans very well. I could see that we seemed to do best when we run small experiments and learn things, and I didn’t have all the language for it that I have now around complexity and collaboration and all that. I just had the sense as someone fairly new to software development or professional software development at the time, that people do things in a way that doesn’t seem to fit how people actually work.
And so, the thing that attracted me to what became the Agile movement is these people seem to be doing things in a way that fits humans. So when I first went independent in 2008, I named the company Humanizing Work, and then that disappeared for a while when Bob Hartman and I did Agile for All, and then Humanizing Work is back now, but that theme has gone all the way through where I see things like Scrum as tools for humanizing work.
Now, sadly, they’re not always used in that way. I can think of plenty of examples of people using the Scrum words in a really dehumanizing application, but I don’t think it has to be that way.
Michael
I wonder for either of you, can you give a specific example of something that you used to emphasize back in the day and now you deemphasize, or you don’t talk much about at all, that’s related to the Scrum framework?
Peter
I can. {Yeah, go ahead, Peter). I used to be much more focused on how to do things like estimation and task breakdown and sprint planning and kind of the tactics that we should use in a sprint around like burn down charts. And it was kind of like this whole toolset and a lot of that evolved out of, well, here’s what worked on our team, so do that. And the more I realized that, like the thing that worked on our team might work on other teams, but it might not. They might have something better or they might not need that thing. They might not have the problem we were solving with that. The less I’ve been a strong advocate or even taken a position at all on some of those tactics to use around and within Sprints.
I remember a specific example of that when one of the first teams that I trained outside of my own was the product team called After Effects at Adobe. Fantastic team! That team had been around for 20 years before our company was even acquired by Adobe and these were really fantastic engineers. They, by the way, I just want to shout out to the company name.
So After Effects was part of a company that was acquired by Adobe just like ours, and their company name before they were acquired was COSA, which stood for Company of Science and Art. So yeah, what a beautiful company name and the employees of that company and then the members of the After Effects team really did a fantastic job of blending science and art.
So I taught them how to do story point estimation and all the reasons why story points were so much better than time estimates. And they sort os said, “Okay, we’ll do it.” And I remember about three months into it talking to the Scrum Master on that team saying, “Yeah, we’ve abandoned that whole story points thing– like our engineers have been estimating in time for a long time.
They’re really good at it. They get good estimates and using story points just feels like busywork to them. So they’re back to just estimating time.”
And at the time I thought, “No, they’re moving backwards. They’re backsliding on all of this agile stuff.” And these days I would just say, “Fantastic, That’s great. I’m glad you found that. It works better for you all.”
Richard
That was the first thing that came to mind for me. Estimating, capacity planning. Some of those things used to seem so important, and I recognize those things often need to happen in some way, but it’s not how I would spend limited time with the team. What are we going to focus on the most? The other thing that came to mind was that team size used to seem really critical, and there certainly is research showing that small teams communicate more effectively and there’s that sweet spot around five or six people in the research. That said, I care so much more now about locating complexity within a single team as much as possible, even if that team is larger, at least in the short term, I would rather see even a 20 person team that can complete complex backlog items. And then over time you build up, with cross-training, more skills, more T-shaped people on the team. Maybe you can split into two separate smaller teams at some point. But breaking into two small teams and then having them have to do all kinds of coordination or even collaboration across the team to get anything done–I’m embarrassed when I think back to some of the times I recommended that and how much coordination these two teams had to do to get anything meaningful done. They should have just been one team. That’s a really big change for me and contrary to the guidance you get in the Scrum Guide, but with the lens of complexity and Scrum as a tool for complexity, I think it just makes so much more sense.
Peter
Michael, how about you? Flip it around.
Michael
Yeah, thank you. I’d say, like Richard, my journey started with XP at a time when carrying that book around Hewlett-Packard or my part of Hewlett-Packard could have been seen as an act of insubordination. You know, it was a threat to established systems and ways of working. So that seemed important to me that people could get so worked up about something that seems so clearly better than what we were doing.
Turned me on to it. Sorry. The Agile movement, broadly. My first deployment of Scrum also had some tension behind it because I transformed a marketing team. We adopted Scrum in a context of an engineering culture and that was very, very upsetting to the engineers, to the point where, you know, I had countless lectures about how this couldn’t be applied to anything outside of engineering, told to stop doing it, etc.
So again, I was curious about such a strong, opinionated reaction of something that seemed to be common sense. Why wouldn’t we deploy this? Why wouldn’t we use clearly better ways of working that protect the team, that allow people to thrive, that encourage innovation and learning? And I would say a part of my journey, I think, was also a draw to trying to address profound dysfunction in organizations.
And Scrum seemed like a really useful tool for that. Less about the dogmatic application. Like you have to do this, you have to have a full time Scrum Master on your team. You have to have, you know, retro immediately following demo or, you know, it’s something like that level of application. What was interesting to me is where does it actually provide a vehicle for teams to thrive in contexts where they weren’t previously thriving?
And what I’ve noticed over the years is to me it’s less about calling it by name, Scrum, and more recognizing that a lot of the recommendations that we pick up outside of Scrum theory, Scrum practice, can be addressed by “Let’s use Scrum,” right? You know, in the world of remote work, the importance of communicating more with your teams, your colleagues, than maybe you have in the past–well, that’s something easily done with Scrum. You have a daily Scrum, everyone gets together– the subversion of kind of traditional command and control orthodoxies for bottom up approaches. Well, Scrum helps with that. It has to if you’re actually trying to apply it and not use it as a tool of oppression. And it just seems like it’s hard for me to read something out of HBR or any research these days without saying, “Wow, they’re talking about a lot of the useful things that come by default with this framework.”
“Why not just start with the framework, and adapt from there?”
Peter
Yeah, I think.
Richard
That’s well put.
Peter
(continues): I think the thing that triggers for me, Michael, is that I don’t think I’ve ever changed much my belief that the four events in Scrum are useful patterns. However, the way that Scrum defines roles I take with a huge grain of salt these days, like the fact that you need a full-time person who is a facilitator, coach or impediment remover or all of those things.
There’s just plenty of examples of really healthy teams that don’t have somebody that’s devoted that full time and really hard to find somebody that has that skill set and even difficult to train somebody to have that type of a skill set. Really, they’re trying to find the team gel person that’s just really hard to identify. And the idea that you need a single person wearing the hat of product owner in order to be successful.
We just have again plenty of counter examples of small teams that are doing the job of product ownership, but having that be a single [position]. So the roles or something that I have, I’ve stepped back from quite a bit in my advocacy of “Thou shalt have these roles in order to be successful.” But as you describe to the events, I thought, yeah, those four things are just human patterns.
We’re going to plan a little bit of work, we’re going to plan how we’re going to coordinate or collaborate today. We’re going to check in and say, How’s the work going from a customer standpoint? How’s the work going from a teamwork standpoint, make some improvements there and keep going. Those things, I think, are the core patterns of Scrum that I find useful almost no matter what.
And then all of this stuff around how to get good prioritized work, sliced down to thin things– All of that’s really valuable, of course, whether you’re calling it Scrum or not. So, violent agreement with you there on that.
Richard
Well Michael, thanks for joining us on this week’s show. Bring in an interesting question and being willing to jump in on the conversation with us about it.
Michael
Thank you both. A pleasure to be here. Maybe something a little bit more genuine, really. Thank you both. You’ve traveled with me on really an amazing journey through the years and I feel like you’ve profoundly impacted how I think about work, how I think about teams and people on teams and with Scrum, with Agility, I have now multiple lifetime’s worth of interesting things I could choose to explore and bring back to– you know– the way I think about all of this. I’ll never get to them all, but knowing that they’re all out there and all worthy of consideration in some ways, is probably the greatest gift of all. And you surfaced all of that.
Peter
Well, right back at you, Michael. (Thank you.) You’re one of our favorite people to hear from to see you show up at classes and meet ups. And we frequently get great feedback from Michael on even just a thing that we’re trying. So you’re always so willing to help. And all of our work gets better because of your involvement in it.
So thank you for that.
Richard
If you’re listening, we want to hear from you too. So weigh in in the comments on YouTube or social media, how has your own thinking about Scrum and the things around it changed over the years?
Peter
And of course, please like and share this episode if you found it useful and keep the questions coming. We love digging into these types of topics, so send them our way. And thanks again, Michael, for bringing us this one.
Last updated