Do We Need Agile Process Frameworks Like Scrum?

Jade Meskill:  Hello. Welcome to another episode of the Agile weekly podcast. I’m Jade Meskill.

Roy van de Water:  I’m Roy van de Water.

Derek Neighbors:  And I’m Derek Neighbors.

Agile Process Frameworks vs Individuals and Interactions

Jade:  I thought today, we’d talk about something, maybe a little controversial. Do we need frameworks?

Roy:  Like Rails?

Jade:  Maybe like Scrum. What do you guys think?

Derek:  No. Yes. No.

Jade:  OK.

Roy:  It’s one of those things where they’re helpful to get started by get in your way after a while, but you think they get in your way a lot sooner than they actually do.

Derek:  I like to say, if its individuals and their actions over process and tools. Why is it the first thing that we default to add to lists are hey, you need to learn a bunch of process? I think, no, they are not necessary.

However, it’s very hard to do things well if you don’t have any discipline. What process does is it allows you to learn how, as a team, to be disciplined about the work that you do. It helps highlight issues that you have that can help you improve. Basically it builds off of work that people have done before.

We know that all these things tend to really keep teams from performing well. If you’re not cross‑ctional, if you don’t have a concept of time boxing, if you don’t have a number of these things, you tend to struggle.

We’re going to go ahead and put those things before you. Learn how to use them, and as you learn how to use them, you can shed them away and probably still get really good results.

I’d say, yes and no, I don’t think you need process. Do I think that it’s hard to be good without having some guide rails to explore how you work? Yes.

Agile Process Frameworks as Guide Rails for Novices Only? (Dreyfus Model)

Roy:  I think some of it comes down to pragmatic thinking and learning talks a lot about the Dreyfus model and how early on you need rules because you don’t have enough knowledge to make your own decisions. But that rules ruin experts, and all these people that have lots of experience are now hindered by having to follow these rules when they should be trusting their intuition.

Derek:  People tend to find themselves being experts far before they’re really experts. That’s another problem there is. I call it the so fucking agile. We’re so fucking agile that we don’t need to do XYZ. I can turn on the dime. I can respond to anything. I was just like, Yeah, so you’re in chaos. That’s really great.

I don’t consider that agile. Never getting anything done because all you do is respond to every stimulus that comes your way does not make you good. It makes you undisciplined. I think that that’s difficult thing.

Roy:  I think that’s the careful distinction between thinking that you’ve arrived, that you’re there and that you’ve finished adapting Agile or whatever or finished improving and the idea of, I think I’ve grown these rules but I still need to improve and try new things all of the time because I’m not even close to where I want to be yet.

Derek:  Yeah, so the litmus test I use is if somebody believes that the rules don’t belong to them and they don’t want them. They’ll throw a fit if they have to follow rules, they’re probably not really a master. If somebody says, I think that these rules could be bent but I don’t really have a problem with the rules and if it’s going to cause you all sorts of grief to not adhere to these rules, then fine, I’ll adhere to them.

I generally find that’s the person that’s probably OK without actually having rules because what they’re saying is, I don’t think the rules hinder me so much that I can’t be effective, but I do think I know the rules well enough that when they need to be bent in certain ways, I could get more performance out of them.

Where the amateur tends to say, I just don’t want the rules at all. Any rules at all are going to hurt me.

Roy:  I agree with that.

Dumping Frameworks on Teams. More Helpful or Harmful?

Jade:  Part of my reason for asking this question is thinking about introducing new teams, new people and dumping this giant framework on their heads, let’s say Scrum. If I’m going from nothing to Scrum, that’s a lot of stuff to learn and take in. Does that hinder or help their ability to become more agile?

Derek:  I don’t know. So you do count them on if you don’t want to do that. I think that to me like what I’ve been…

[crosstalk]

Jade:  That’s even a lot to take on.

Derek:  Not really.

Jade:  To do right.

Derek:  The way that I look at it is, what do you want? If you want some immediate results, a framework like Scrums says, We’re going to be opinionated about a whole bunch of stuff because we know it works for most situations so just believe us and do it.

The benefit to that is you can actually get real benefit immediately by making those changes. The downside is, you have to make fundamental changes on how you work. For a lot of people that pisses them off and makes them turned off to the process so then, they want nothing to do with it. It doesn’t stick long term the minute that somebody says, OK, you don’t have to do, even if we’re getting great results from it, ultimately, we didn’t decide to do all those things.

The framework tools we had to do them so I’m going to throw them away the first chance somebody will let me where I tend to say that people that have a little bit more time, can explore. You do something more like Kanban. Just do what you’ve always been doing, visualize it and start to ask yourself how we can improve, improve over time.

That’s a lot less hostile. People will tend to get to the same place that they get to in scrum a lot of times, but they get there over the course of months or years. They totally own it, because they’re the ones that made all those decisions.

I had a team the other day. One of them was doing the work of what I would call the scrum master. The other person said, We created our own rule for a Kanban, it’s called the … [inaudible 06:06] Nanny.’

It was the person that was helping organize the work with outside parties and working with the product owner and managing a lot of the stuff that developers didn’t want to really be doing, but needed it to happen.

I thought it was kind of ny that after a couple of months of Kanban, they had really implemented the equivalent of a scrum master.

Not because they wanted to emulate the scrum master. It was just that somebody stepped into the role of doing that and people could tell there was a different role than the developer.

I don’t think it’s necessary. I think it can hurt or help.

If you want some immediate gains, if you believe in cross‑functionality and you believe in time‑box and being able to estimate or have some predictable delivery or really important and you want to get that right away. I think scrum can give you those things right away. It might piss people of in the process and turn them off to Agile in general. That’s a possibility.

Jade:  When have you seen the best results?

Derek:  I see the best results when it’s a hybrid.

You don’t necessarily force. You have to do all these things, but you do some kind of principle‑based stuff. I almost think of it like scrum is the best idea of how I would deal with this, but if you have a different way to deal with this, fine let’s deal with this in a different way.

I think that time‑boxing of iterations is a really good way to force feedback in some regular thing. If you’ve got a better way than that form of time‑boxing to do something, cool. Let’s look at it.

More often than not people, given them the choices, just give a better way to do it. Let’s hear it. Very mature, so they don’t know. They’re like, OK, let’s do that, because I don’t have a better way.

Sometimes they come up with a better way like, I think we can do this instead.

Jade:  You’re showing them the facts, but then saying, It’s your choice. If you’ve got a better idea, we’ll support the best idea.

Derek:  Right.

Roy:  That sounds reasonable. It goes really hard to argue with too.

Derek:  It’s about not being dogmatic. At the end of the day, we just want results. As long as we’re all OK with the results.

Roy:  If you can manage to get awesome results with Waterfall, then by all means.

Derek:  To me, with cross‑functionality, people get really hung‑up on it. I like to switch it more toward shared commitment. As long as we’re all shared in the commitment and that any of us are willing to do the work and all of us are part of that, I’m OK with not necessarily calling it cross‑functionality.

It’s impossible to get that result and to have shared commitment without having some level of cross‑functionality, but if somebody’s going to get totally hung up on like, I’m a DBA. There’s no way I could do XYZ.

Great. Let’s not talk about it in those terms. Let’s just talk about it that we’re bringing in two stories. The three of us are all going to commit in doing those stories. Let’s not predetermine who’s doing the work and we’ll go from there.

Roy: It reminds me of something Jim brought up in one of our earlier podcast when he joined us.

The idea, “We just care what is effective. The fact that it happens to be what makes people happiest is just a really nice coincidence and side‑effect but really it’s all about getting results.”

Where It Goes Wrong? Measuring Agility by Process Adoption vs Results

Jade: Maybe that’s where some adoptions go wrong, the desire to state is to be doing scrum, not to be getting results.

Roy: Especially when you start measuring how far along your scrum adoption has gone.

Jade: I’ve seen a lot of corporate roll‑outs in large companies. Really, the goal is to have scrum. It really is not about delivering results.

Roy: We are more agile than you.

Derek: No, I think it’s more, better, faster. What we really care about…

[crosstalk]

Roy: No, but they’re not even tracking more, better, faster. They’re tracking the ability to adhere to the scrum frame.

Derek: No. In most of them it’s, is your velocity increasing over time. If you’re velocity is not increasing over time, we’re going to get mad at you.

One of the ways that we track like are you getting better is ‑‑ are you having stand‑ups? Are you doing retrospectives? Are you doing a planning meeting? What’s your velocity?

Jade: Measuring the rules of scrum.

Derek: It’s measuring the ceremonies and the rules of scrum, not the results of the scrum team. That is one of the things that actually kills scrum.

It shouldn’t be about any of those things meaning if you can’t get better by like…We’ve been trying to say while I’m on my current engagement is you will do Scrum or Kanban for two to three cycles or two to three sprints, whatever you want to call it, in roughly 30 days, give or take, in a fairly pure form to whatever the methodology or the thing is. From then, go ahead and make whatever changes you want.

One of the major means for change for me is, have you started to change it. Because if you haven’t, I don’t think you’re really agile because agility starts to say like, “OK, we’ve done this and we now know what we could do better that works for our DNA or organization or team.”

The second part is measuring are you getting real results, not is you’re velocity better, not are your sprints cycles order, not with a bit like are you getting whatever results the business wants from you. If you’re doing those two things, you’re good to go.

Jade: So, it really comes down to results?

Derek: I think so.

The Journey of Adoption vs The Destination of Framework Adoption

Jade: Great. What advice would you give to people who are out there who are maybe in the midst of this transformation or adopting Scrum or thinking about adopting Scrum? What would you tell them that would help them become more successful?

Derek: For me it’s a journey not about destination. I mean, too many groups, teams, organizations I look at and say, “Hey, we were going to do an agile adoption or an agile transformation and we want to be done in two quarters or we want to done in a year and a half.” So, they put all these effort and like to we’re adopting something whether be Kanban or whether be Scrum.

The end is when everybody in the organization is doing that process. For me, if you want to be successful, don’t think of it as a destination of we’re successful ones everybody is doing for some process, think of it as this is a life long journey for your company.

You have to constantly be adapting to the world around you. Part of it is you should be asking yourself if you’re still doing to same Scrum thing that you were doing or the same Kanban thing that you were doing a year ago, you’re not adapting because I guarantee your world is changed in a year, year‑and‑a‑half time‑frame.

I think part of that too is if you’re not seeing your team change and you’re not seeing your result improve, there’s something wrong with what you’re calling agile.

Jade: And results, not velocity, not your scrumness ‑‑ your actual results.

Roy: The thing I would look at the two is to think about why you’re being asked to change. Because with some of the teams, I think that they are…because they happen to be the best team in the company and for some reason think they are the best team within their immediate surroundings. They think that they don’t need to improve at all. So, that would be my biggest advice as I just assume you suck and get as good as you can.

If You Don’t Think You Suck, You’re Probably Already Dead

Derek: If you don’t think you suck, you’re probably already dead. What I mean by that, that analogy I give all the time, is if you look in a gold medalist in almost any sport when they’re standing on the gold medal platform or getting their gold medal, they are more likely not thinking what an awesome performance I had.

They are thinking about every single mistake they made that they could have done better even though they’re already getting the gold medal.

They’re saying, “Man, if I would have stuck that, I could have got a perfect 10 or I could have shaved an extra five seconds if I would have picked up my foot up or man, I had a bad start out of the gate and if I would have fixed that, I could have beat the world record.” No matter what their performance is they’re sitting there going I could have done something different to go better.

That is where exceptional teams, exceptional individuals come from as when they look at even their best performance and say, “Man, I can do even better. I can find another way to make this better.”

The people that tend to be mediocre, the people that are like, “I’m great, I did the best I could there. I could not be possibly get any better.” Because the minute you said that even if you are the best, somebody else will come behind you that wants it more that what you want right now and take it over from you…

Roy: Then they’ll make it look easier for you.

Derek: There was a time when there wasn’t such thing as the four‑minute‑mile, right?

Jade: Yes.

Derek: I mean that seemed impossible but once it was four‑minute‑mile, it just keeps going like there’s always somebody who will find a way to outperform whatever you think the best performance is especially in technology because we’re not limited by physical means.

Somebody will invent a better mouse trap that will surpass whatever you think is the pinnacle. If I were to say we’re going to travel beyond the moon and land and to do something that might seem impossible today but once that happens and it goes the next level and the next level and the next level, somebody will always one‑up that.

That is a huge factor. If you’re not looking to improve like why are you doing agile, like if you think you’re great? I also think there’s a big translation problem between executives and middle management. Executives what I hear most executives say is “I am sick of not being the best in market, I’m sick of not making our customers happy, I’m sick of not being like number one.”

What management tends to hear on the technical level is they want us to be faster with better quality. When middle management tries to adopt agile, it’s really all about how do we get agile? Do we have better velocity, less defects?

The reality is if they produce the same shit with more quickly with the same amount of defects, their manager…their executives would still be asking for something different because what they’re really asking for is how do we outsmart the other guys that are on the platform with us.

Roy: Right. They don’t want a faster horse. They want a car.

Derek: Right. Exactly.

Roy: They want something that may change it.

Derek: Exactly. That’s exactly it. That’s one of the things that’s very difficult for teams to realize too because they’re just like, “OK, we just need to go faster, we need to work harder.”

So, a lot of the agile initiatives are seeing this kind of like, “All right, great. Somebody got a whip out” and they’re just beating us hard with this process. Instead of saying maybe this is a process that actually frees us up to be co‑creators of something great instead of just going faster at the crap that we’ve always done.

Jade: That’s all the time we have here today. Thanks for listening. Catch you next time on Agile weekly podcast.