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 think it was because it made us uncomfortable and was not part of our culture that we wanted to resist those foreign elements coming in to how we do business. Once we got over that and started to pay attention to the benefits that the constraints were giving us, that’s when it became much easier to accept those limitations, embrace them, and actually use them to make us better.

Clayton:  So, it’s good that you bring up the idea of the concept of constraints. I think where the article drives towards, eventually, is that there are certain sets of constraints that every application, every agile methodology is going to have, whether it’s Scrum or whatever. You’re going to have these constraints and maybe you just need to make the choice that, if you can’t live within those constraints, then maybe this isn’t the right framework for you. Do you think it is appropriate to say that if you can’t live within these constraints of Scrum, don’t do Scrum at all? Or is it OK to, maybe, do parts of Scrum?

Jade:  Yeah, I think there’s great parts of Scrum that are really great that’s practices. No matter what it is that you’re doing. No matter how what you want to apply the framework. So, I certainly think that you can pick and choose certain practices from Scrum, but I don’t think that you’ll get the full benefit. You won’t see the maximum effectiveness without embracing the whole thing.

Chris:  I agree with you. It think that there’s so much that practice is built upon the other practices to help bring the teams together and to help everything work better and to achieve that efficiency. People that cut and chop it up, they never realize that. Then, it gets even harder for them to understand why some of the points that they’re trying to stay with, why they’re painful.

Clayton:  Yeah, so, I guess to wrap up. What are some ways that if you’re on a team and maybe you’re trying to adopt scrum and you’re feeling like it is inflexible…Where do you reach out or how can you be sure that it’s the framework that you’re running into versus something that’s inherent to your team? That’s baked in. Maybe a bad practice that you already have.

How do you know which is which? How do you approach that problem?

Drew:  I think that’s something that’s very difficult to discover. Especially if you have very little experience with it, I don’t think that you’re going to be able that determination without getting some kind of mentor or bringing in somebody that has more experience or…

Even if it’s just an outside person that’s not so closely attached to the problem, is able to make that determination a lot better than you so far, especially if you’re just starting with it.

Roy:  Also, I think…

[Cross talk]

Drew:  Go ahead.

Roy:  Also, I think that…how do I determine if this is just not right for me or if I’m doing it wrong or what…the cool thing about Scrum 2 is the inspecting adapter, the iterations. So, how about for one iteration or whatever you want to call it, you hardcore try this principle of Scrum that you don’t think applies to your team?

Maybe you have to do it for more than one iteration, but at least for one and inspect and adapt. There’s always obviously going to be the first uncomfortable part about it. But, try it out. I think that’s a huge thing. Even if you don’t think it applies. A lot of people say it works. Try it out and see what the results are.

Jade:  I think that’s good. Going back to what Roy said, I think it is challenging to see from the inside your own problems.

I do think it can be done, but you have to be almost psychopathically dedicated to looking at yourself and introspecting and really digging deep all the time and pushing the limits, all the time of what it is that you’re doing to see where the core problems lie and what’s really going on.

So, I think you can benefit from a third party because they’re not weighed down by all that baggage, but it’s certainly possible to overcome yourself and your own challenges with a lot of hard work.

Clayton:  All right. Thanks, guys. That brings us to next time.