Is the Process the Problem?

Episode 61

May 24, 2012




The Agile Weekly Crew discuss Jamie Flinchbaugh's article Don't Just Change The Process If People Aren't Following The Existing One.

Episode Notes

Drew LeSueur, Derek Neighbors, Clayton Lengel-Zigich and Roy van de Water discuss an article by Jamie Flinchbaugh entitled Don’t just change the process if people aren’t following the existing one.

Is the process really the issue?

Process only highlights culture problems, it doesn’t solve them

How do you know when it really is time to change the process?

A short feedback cycle is important to evaluate the problems that are being highlighted.


Drew LeSueur:  Hi. Welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur.

Derek Neighbors:  I’m Derek Neighbors.

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich.

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

Drew:  Today we’re going to be talking about an article by Jamie Flinchbaugh titled “Don’t just change the process if people aren’t following the existing one.” The article talks about how people focus on the process and following it to the tee, as opposed to questioning whether that’s a correct process. What are you guys’ thoughts?

Roy:  I don’t know. It sounds like it could be very easy to abuse. It sounds like an invitation for scrumbutts, or any other process butts, “Well, it’s a problem with the process.” I guess this is, actually, saying don’t change the process. Actually, I like that. I guess maybe it’s not a scrum‑but right. It’s saying, just because it doesn’t work for you, maybe it’s not the processes fault. I completely turned around right there. [laughs]

Derek:  What I see a lot of times are people get so hung up on their process as the problem. I think what he might be saying is, if you’ve got a process, and people aren’t following it well, what makes you think they’re going to follow some new process? Even if they are following the process, is how do you know the process is really the problem? Meaning, if you’ve got deep culture issues, or you’ve got leadership problems, or you’ve got visioning problems, process does not solve those.

All process does, especially if you’re talking Scrum or Agile, Kanban, all it does is highlight problems. It doesn’t actually solve them. If you just say, “Here’s process A,” and we run through it, and it highlights all these problems, and we go, “Hmm, yeah, let’s not do anything about these problems, let’s just switch to another process, and maybe if we have to have that process those problems won’t exist.” Then that process highlights the same exact problems, at some point you have to deal with the problems.

Drew:  Derek, how often have you found that it actually is the process that is the problem within a company? Has that ever happened to you? Or is that something that happens generally speaking and this is an exception where it is?

Derek:  I’ve never seen the process be a solution. I have seen a lack of process, or no process, make it so that a company or a team does not know what the problem is. I think sometimes you have to jump into a process to help highlight what the problems are. But, ultimately, the process never solves the problems, it just highlights them.

If you’ve already got a process that’s highlighted a bunch of the problems for you, I wouldn’t advocate going and switching to another process. I would deal with the problems that your current process is highlighting. If you have no clue what problems you need to tackle, then maybe you need some process to help highlight the problems for you.

Clayton:  Yeah, I think that one example that comes to mind is you might find a team that is doing Scrum, and they never have enough time for planning. Like, every time they say, “Scrum, the process says we have to do this thing called a planning meeting,” and it has these certain things we have to do, and there’s this artifact or whatever that falls out of it. But we just can’t just do it.

Either the work we’re doing is too complex and we don’t have the time to break down all the work that we’re doing in this planning meeting, or there’s just not that much time in a day. They told us we have to do this two week sprint thing, so we can’t spend two days. That’s too big of a percentage of our Sprint just doing planning and thing that’s one of those situations that Derek’s getting into is, “OK, well, maybe there is a problem. Why does it take so long to plan?” Or maybe that’s not even a problem. Maybe that’s OK. But I think that’s the kind of thing that people will dive in and say. “This process is broken, it doesn’t work!”

Roy:  Does that mean that maybe processes like Scrum, and like some of the other ones out there are really just a way to normalize your team, so that you can talk in the same language as all the other teams? For example, having the issue of not being able to spend the time for planning, you might be able to go to another team that is practicing Scrum, and say, “Hey, we’re having this problem, and because you guys are using the same terminology, and you are trying to implement the same process, maybe all it is, is a framework to make it easier to communicate your problems to other teams, so that they are able to help you out.”

Clayton:  Yeah, that probably would make it easier, but I don’t think that’s really the goal so much as the teams have probably going to all have some different kinds of problems. They are all going to be exposed in some different way. I think it’s kind of, you get to that fork in the road, where either you decide to, “OK, well, here’s this problem we have. We’re going to resolve it somehow.”

I think what the gist of article is, “We have this process problem. It must mean that we’re not doing something about the process right so let’s stop doing this and find a new process.” That’s the real issue. A lot of times, the stuff that something like Scrum or any agile methodology will uncover are difficult things that you would rather not have to solve. It’s a lot easier to blame it on the process, do some new thing, “Here, look, look, a pony.” You get some new thing in there, and you can kind of start the cycle over again.

Drew:  We have some processes out there that I feel like most of us consider negative processes. I think, in most circumstances, for example, waterfall is pretty much frowned upon in the agile community. There probably is a time and a place for it, but how do you make that determination?

I suggest if the entire agile community shuns it, then we can’t consider it a valid process. It might be the process that is a problem. How do we know that it is my process that is a problem, or how do I know it is my team that is a problem? Do you know what I mean?

Derek:  I think a process lets you know what challenges you face within a team or an organization. I think the reason that waterfall has been universally shunned over or shown to be not so effective is it’s feedback cycle is way too short. It does have the ability to tell you that things are wrong, and to deal with them. However, the time frames that that are in are generally in months or years as opposed to days or weeks.

I think when I look at why most agile processes do fairly well is because they’re very iterative, which means they’ve got much, much smaller feedback loops. I would almost argue that a lot of teams I see doing scrum are really doing mini‑waterfall.

Their teams are still very siloed. They’re doing two or four‑week sprints. In whole, they have iteration zero, and they have a hardening sprint. They have all these smells, but they are getting feedback in a much tighter loop than if they said, “Hey, we’re going to do this 12‑month project, and we’re not really going to do a postmortem until month 12.”

Clayton:  Just to clarify, I think you meant to say that they have a longer feedback cycle?

Derek:  Yes, longer feedback cycle. I’m sorry.

Drew:  When people have resistance to part of the process ‑‑ like, “Oh, we can’t spend all this time planning” or “This standup is just getting in our way. Why don’t I just get my work done?” ‑‑ part of a lot of agile processes are ceremonies that may be uncomfortable for people who are trying them to start.

What are ways you guys think to overcome those type of awkwardness of starting a new ceremony that, by their culture, they’ve never done before?

Roy:  I think a lot of it is providing value in those ceremonies. I see way too many organizations institute a standup or a planning meeting. They are pretty much dog and pony shows in the sense of, they are there only because some scrum book or some scrum master or some coach told the team they need to do that, but the teams get no inherent value out of them.

I think the key is getting the information out in the ceremony, dealing with it, reflecting on it, and improving the ceremony every time. Otherwise, what’s the point? There’s been several times I’ve told teams, “Why do you even bother having a stand up, because what you’re doing is not valuable to yourselves or anyone around you?”

Clayton:  Going back to the article about, “Don’t just change the process,” when do you guys think it’s OK to change a process? How far does it matter to team maturity?

Or if you get to try it for a certain period of time, how would you know now is the right time to change things and do something different even just as an experiment? How would you know how far to go with that? If you keep that for a longer period of time, is it OK to change pr