“How Rigid is Scrum”

Episode 29

October 12, 2011

13:38

TBD

tbd

The Agile Weekly Crew discuss an article How Rigid is Scrum

Episode Notes

Clayton Lengel-Zigich, Roy van de Water, Drew LeSueur, Chris Coneybeer and Jade Meskil discuss an article on InfoQ, “How Rigid is Scrum“.

Rigid up front

Flexible with experience

Inspect and Adapt

Breaking rules is usually to avoid a deeper issue

Learn through imitiation, then improvise

Set in stone Scrum is not ideal

The uncomfortable parts of Scrum will expose issues

Culture can stand in the way of Scrum adoption

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the Scrum Cast. I am Clayton Lengel‑Zigich.

Roy van de Water:  I am Roy van de Water.

Drew LeSueur:  I am Drew LeSueur.

Chris Coneybeer:  I am Chris Coneybeer.

Jade Meskill:  I am Jade Meskill.

Clayton:  Last week, I had sent out an article to the team that I’ve found on InfoQ. The title was “How Rigid is Scrum?” And, kind of, It’s a collection on different quotes and some observations that people have made about the flexibility or a lack thereof of the Scrum framework.

Just to get going, what’s everyone’s opinion? Is Scrum flexible or inflexible framework?

Drew:  This is Drew. I would say that it’s flexible. Because, it’s overall very simple. It’s got a couple of artifacts, a couple of ceremonies and just your basic structure. In between that, there’s a whole lot of room for movement, for change, for inspecting, and adapting. Because of the overall simplicity, you can explain the general idea to somebody, in maybe, 10 minutes, or so. There’s a lot of room for change.

Roy:  I think that Scrum should initially be rigid, and become more flexible over time. It is a good starting off point, you get yourself to that point, and then start adapting, and figuring out whatever works best for you. That produces the best results.

That means doing things that Scrum allows for. Sticking to Scrum by the book, you still have a lot of flexibility to do your own thing. Even breaking some of the rules of Scrum. As long as everybody is on board with what is going on, and you try one, or two things at a time, so you minimize overall risk, and are able to measure the impact. I don’t see anything wrong with that.

Chris:  This is Chris. I agree with Roy, and I think that that’s specifically, what Scrum was built for. That it’s built to be rigid. At first, not rigid, but it’s built to be something that you can follow, and you can learn from, and then adapt, and change. I don’t think it’s rigid overall, no.

Clayton:  It’s funny that you mention, the idea of, Roy, of maybe it being inflexible, or rigid upfront, in doing Scrum. One of the detractors in the article mentions that, it sends alarm bells, when a team says that they are going to do Scrum by the book. Another point in the article mentions that, some teams seem to Scrum by the book, and they make it very rigid from the start. They’re afraid of doing it wrong, and they just want to make sure that they are doing the right thing. Do you think that that’s a mistake?

Roy:  I don’t think that that’s a mistake, and I think I brought it up in a previous Scrumcast. Which, is that a lot of times when you’re first gaining experience with Scrum you want to break some of the rules of Scrum because it’s easier. What I said before that you can feel free if you know what you’re doing, and the entire teams on board, and all of that, and you’re measuring the changes, and you’re breaking the rules of Scrum. I don’t mean that you’re doing that to find something that’s easier. I mean to find something that’s better. That gets more business value, and that produces a more reliable result.

I think a lot of times people will take a particular rule, like let’s say one product owner, and they’ll say, “Well, that doesn’t work for us, because we have a whole bunch of different people. Let’s just set up a whole bunch of product owners, and we’re just going to go ahead and break their rule. Because that doesn’t work for us.” That ends up causing problems down the road, and really what they’re avoiding is they’re avoiding a really difficult conversation where they start having to make decisions. Instead they just cater to everybody at once, and that ends of not benefiting the entire team in the long run.

Clayton:  This came up at Agile 2011 in somebody’s talk that I was in, and they made a great reference to Pablo Picasso. They brought up some of his very early works, and they’re very traditional paintings that you would really expect from a normal painter. What he said is that Picasso had to learn the fundamentals and the basics of painting, and how to paint, and how to replicate exactly what he was seeing, before he was able, to then throw out all the rules. Break all the rules, and come up with amazing innovative paintings that he was able to create later. I thought that was a really good way of putting it.

Chris:  This Chris, I just want to add to that, and the fact that I’m working with a team off site right now. I think that some of the problems I had when I first got with this team, really come from where they took Scrum, and they wanted a process because they were so used to having processes and waterfall before. That they treated that process as if it was inflexible. It wasn’t’ that Scrum wasn’t inflexible. It was the way that they treated it because it was their culture, and that was the way that they were used to doing things. I think if people are going in, and they’re being well coached, and they understand that this is so that you can learn and make decisions later, and then you make changes based upon what really works for your team instead of just when it hurts. That it can be a great platform for you to start building upon.

Clayton:  That brings to another point that someone made to the rigidity of Scrum. Is they mentioned that they didn’t really like the stand‑up meeting, because they felt that the 15‑minute time box, and the idea that each person was going to say their piece and move on, didn’t really let spontaneous knowledge sharing occur. It was hard to have a 15‑minute time box because the team would be going in a certain direction that they thought was a productive direction, and they were having a good conversation and then the stand‑up had to be over.

Is that a misapplication of the stand‑up rules? Or is that the purpose of the stand‑up, to keep that stuff short and maybe not everyone benefits from that or not everyone agrees that they were going on the right path?

Roy:  I think that’s a good example, where the stand‑up rule should have applied. It makes actually a lot of sense, because there were certain members of the team having a great discussion that they felt was really productive. What you don’t know is, either two or three or four or however many members of the team felt that this was wasting their time, because it touched something that they had nothing to do with.

So, I think that the 15‑minute stand‑up would have allowed it to come up, so everybody who’s interested, is aware of it, or everybody who feels like they’ve something to contribute is allowed to become part of that spontaneous interaction. Then, push it towards offline, so you stick to your 15‑minute time box, and immediately after stand‑up, continue the discussion. Only with the people that want to be part of it, and feel that they’re able to contribute.

Drew:  Yes. For example, today with our team we had a spontaneous…you could call it a meeting, but it was more like a team conversation, where we even pulled in more stakeholders and it was spontaneous. Just because the scrum framework doesn’t prescribe any spontaneous meetings per se, it doesn’t mean you can’t do them.

Clayton asked if that was a misapplication. Let’s say if there was a legit purpose for extending a morning meeting longer that didn’t follow within a stand‑up, you can call that just another meeting, I would say.

I do agree with your point, Roy, that if something is uncomfortable to have a rigid stand‑up, it doesn’t mean you shouldn’t do it. Try to do the uncomfortable parts of Scrum because it might expose issues. You really have a great point there, probably two or three of those people aren’t getting anything out of that extended stand‑up.

Clayton:  Is there a chance that some people might confuse, regardless of the agile methodology, having a rigid system or the system being inflexible with something that’s maybe exposing a bad behavior that they currently have on the team? Something that they’re used to doing, that maybe they shouldn’t be doing, but it feels wrong not to do it, and so they inappropriately apply that as an inflexibility of the methodology.

Roy:  Got you. Like for example the multiple products or anything like, “Oh, well, Scrum is all the fuss because it requires only one product owner, and that’s just not possible,” something like that.

Clayton:  What are some examples of where, maybe people, for this particular instance, are used to having long morning meetings that one or two people think are very productive, but everyone else in the team thinks are not. It would seem that the 15‑minute time box is restrictive.

Roy:  Or, another example could be, “Our development cycle’s too long, there’s no way you could have a four week spread like that, that’s never going to be able to happen. That’s a limitation of Scrum that doesn’t fit our eight‑week cycle model.”

Jade:  I was thinking back to where we first started adopting Scrum inside Integrum, and so many things that we said were impossible are the things that we do every day. I thin