When Scrum Teams constantly push back on changing priorities, stakeholders begin to blame Scrum for the rigidity. Teams with large investments of time and energy are resistant to change. Break up this rigidity by delivering the smallest possible value. Get feedback quicker. Start anticipating change and embrace it.
Greg: Hey, Robb, I’ve got a question from somebody asking about their team. They’re using Scrum, but they feel like things are a bit rigid.They’re kind of stuck in a sense. Like Scrum isn’t working like maybe it’s broken. Any thoughts on that? What have you observed when teams are kind of stuck?
Robb: Well I definitely talk about rigid being the opposite of agile. Teams that are nimble and lightweights are the opposite of the teams that are sort of stuck in concrete and can’t change and can’t move. So yeah I guess that makes sense. Rigid teams have a hard time with priorities changing, and they get to a Sprint Review and they hear new ideas from stakeholders. And it’s like, ‘Oh great. Now we’re going to make a change’. But that’s the whole point of using Scrum is to be able to accommodate change.
Greg: True. Well so yeah, in a sense you could say Scrum is broken. If somebody’s not really accepting the idea of change then that’s a problem. If the product that you’re working on in the context doesn’t really have a whole lot of shifting change as part of its context then hey maybe you don’t even use Scrum — like we talked about before — but if you are using Scrum and things change around you. Then we’ve got to embrace it. I wonder how people can sort of get beyond this rigidity mindset. What are some of those blockers? Why are people so resistant to change?
Robb: Well, as a former developer myself, I know how it feels. You work for weeks and weeks on this thing and it’s beautiful and it’s your baby. You bring it to a Sprint review and a stakeholder says it’s ugly, and they want you to change your baby. That’s painful! So yeah, personally when I do something creative I expect somebody’s not going to like it, and so I don’t build too much of it before I get their feedback. So maybe there’s an answer there.
Greg: That’s true. So we’ve got to get people used to change. So what do you think? Maybe smaller little bite-sized pieces of adapting to change versus trying to take such ginormous pieces of work and experiencing that frustration?
Robb: Yeah. I think that would be the way to go. Build something small. Get it to a usable state. Then just don’t add that extra polish yet, and if it’s not required as acceptance criteria or it’s not on your Definition of Done, that’s fair game. So don’t work too hard on something before you start getting feedback that you’re on the right track. Don’t build too many user experience designs. Don’t build too much of a user interface or styling if there’s subjectivity to it. Even architecture, don’t go architect your way into a dark place that you can’t get out without getting appropriate feedback so that you can change and get back on track quicker.
Greg: I think that’s a good tip. So I guess that’s it. if you feel like you’re part of a team and you are kind of getting stuck, a little bit rigid. Maybe try smaller bite-sized pieces, and see if change isn’t so intimidating. Embrace it. You’ll find it probably helps you out.
Robb: Embrace change.