Clayton Lengel-Zigich, Derek Neighbors, Roy van de Water, Michael Vizdos and Jade Meskill talk about the cost of change when implementing Agile in an organization.

• Individual, Team, Organization
• Human Resource priorities
• Rate of change
• Performance reviews
• Emotional response
• Personnel turnover
• Conflict
• Champions

Transcript

Clayton:  Welcome to another episode of the Scrumcast. I am Clayton [?]

Ray Van Norter:  I’m Ray Van Norter.

Jade Meskill:  Jade Meskill.

Derek Neighbors:  I’m Derek Neighbors.

[laughter]

Mike Finnister:  I am Mike Finnister.

Jade Meskill:  We have Derek and Mike on Skype with us.

Clayton:  Today we are going to be talking about the cost of change, when I hear that I think of certain things and I am sure you guys think of other things. I am just curious Derek, from your perspective what is the general definition of that so we can get started.

Derek:  Change or the cost of it?

Clayton:  What do you mean when you say the cost of change? Who are you talking about and who is involved?

Derek:  When I am thinking of this, I think of it both on an individual level, I’m thinking at a team level and an organization level, so I think that a lot of times developers or managers might say, “Hey I really want my team to do Scrum because we’re going to get all these benefits,” and they don’t think about the ramifications that’d happen when they do that. A number of things change whether you implement para‑programming, whether you have a wide open work‑space.

I remember one of the first things to change at Integrum when we really started going full bore is, we went away from personal desks and went to paring station, and just the ramifications of people not having somewhere to put some their personal things, and some of their emotional baggage that came out of that that we had to deal with, was certainly something we never even considered as being one of the byproducts or the problems with that.

Derek:  What happens to HR when you have totally cross‑functional teams and they’re completely dependent on a job title to determine how to pay somebody or to determine how much square footage they get as an employee. I’m a CEO and now I’ve got an actual team that’s doing an implementation that is starting to expose problems with maybe the way I incentivize my sales people, is actually damaging the organization and now I have to think about how I compensate sales people to be different so that they can be a better part of the whole organization. To me it’s what are those elements of change and what can one really start to expect and how you cope with that.

Clayton:  Mike is someone whose maybe experienced some more of this stuff in a large organization. Kind of like what Derek was talking about, where you maybe have a group of people that are cross‑functional and it’s hard, murky water to determine pay scales and bonus programs and those kind of things. What are some patterns you’ve seen, or some things where people get it wrong?

Mike:  A lot of times they don’t involve HR right away. Remember HR in a lot of large enterprise organizations have very different priorities than this little scrum team. Maybe that’s starting to take hold.

You really have to start to get on their radar early, and often, and understand that any kind of changes are going to be maybe years away. Being able to get HR on board is especially important. Especially when you’re talking about the matrixed organizations where you have scrum teams working in large waterfall projects.

Clayton:  You mentioned getting HR involved. There are a lot of times where I think a lot of companies have slow moving HR departments. Or just in general there’s some red tape and bureaucracy. How does that contrast with the way that we think of Agile and the way we think of making change, and implementing things quickly and iterating and those things when the typical life cycle of doing almost anything is usually much longer than, say, a sprint?

Mike:  Part of that involves really, again, getting people on board. Normally when I start teams in large organizations I’ll let them know that they’re probably going to take a hit on their performance evaluations. Like, one in the first year. Because now they’re not being specialized working as cross functional team members, and all of a sudden as a tester, let’s say as a role, they’re being compared to other testers within the functional organization.

With the traditional, “Do you play well with other teams, do you have your nice power point presentations, do you do your executive exposure, do you play nice with others, do you have work on 20 projects at once?” You don’t rank that high against other testers that you’re being evaluated against. So being open and honest about this is really important.

Clayton:  Jade and Derek, as far as the Integrum we have maybe more feedback than a lot of organizations from the management to the employee level just because we’re so flat, but when you have a traditional organization that wants to do performance reviews like Mike mentioned, and they have a very set way of doing those things and mentioning that stuff, I think one of maybe the benefits of Agile you could get into is you could say there’s extra feedback. You know where you are a lot of the time and those kind of things. What’s the reconciliation between those? The traditional personnel review and that kind of constant feedback and being part of a team, not necessarily an individual anymore?

Derek:  So I think there’s a multiple problem. So one is, is the content of the actual performance review relevant anymore? Meaning usually HR has a fairly good amount of weight that they’re allowed to put into how you structure your performance review, and it’s fairly standard to‑the‑book type of format. When you start to talk about being on an Agile team, it’s really more about values, principles, and goals and a lot less about individual duties and what your job is specifically. So a lot of times you don’t have an actual performance review that matches what you’re doing.

Two other problems I really see with the performance reviews are that they incentivize the individual instead of incentivize the team, which is obviously fairly contradictory to Agile methodologies where it’s really about the team instead of the individual. Then lastly is I think a lot of things that go along with performance evaluations deal with ranking employees and pitting this person against that person. They actually create mistrust within a team.

Derek:  So the best I would do if I’m in a situation would be to try to hold reviews or have the discussions that are much more honest, much more true, outside of the performance review and then fill out whatever performance review is necessary to turn into HR to placate them and congruently be trying to get HR to change their practice so that they’re more in line with being an Agile organization as opposed to being the dinosaur organization.

Clayton:  I agree with what you’re saying, Derek, but I also think that we do need to have some mechanism of dealing with the individual as well. There are a lot of ramifications that a poorly performing or a bad fit can have on the whole team. So creating those mechanisms that can deal with the individual behavior and I think tailoring the reviews and the feedback to the very specific individual person at that level is good as long as you are also dealing with, like you said, more of the team context as well.

I think somewhere is a balance between those two aspects. You can’t completely forsake the individual for the team or vice versa.

Derek:  So I think to me where the problem comes in is that most performance reviews are structured towards the skill that you do, and I think that’s a bad way to do it. So if you’re monitoring me for how good of a software developer I am and it has to do with the amount of code I’m producing or the number of commits and, I don’t want to say necessary metrics but, things related specifically to code, I don’t know if that’s a good representation of whether I’m a good individual for this team.

I think it’s Tom Lister. One of the things that they did when they looked at a number of teams in writing their book “PeopleWare” is they asked, “Who do you want to be on your team, and why did you want that person to be on your team?” In almost every organization there was at least one person that was on every single successful project and that, when asked, they were deemed one of the most valuable people on each one of those projects.

Derek:  But when they asked the people why, nobody could put their finger on it. I think what starts to happen is if you have a review that is simply a skill set, are you good binary at this task, yes or no?

Sometimes, you rule out the best people because the best people that make teams successful, are key people that make teams successful, are the people that enable other people to do their best work. I think that, yes, you do need to take things at an individual level and review somebody individually.

But, I think, we need to get to the point where we’re evaluating people individually on how they adhere to the team’s values and how they adhere to the team’s principles, not to specific skills or tasks. Meaning that most people that want somebody off the team do not want somebody off the team because they think they do a bad job. They want them off the team because they think they are a bad fit for the team.

Jade:  I agree.

Roy:  Because, when they are fit for the team, they’ll figure out ways to help that person become confident in the area that they need to be.

Jade:  I totally agree. I guess I was going under the assumption that you were measuring and judging the individual on the proper things. I think that’s a good point to point that out specifically.

Clayton:  Roy is someone who has been helping another team kind of adopt some of these Agile principles and things. What are some of the things that you’ve experienced in terms of the cost of changing, people that have been affected and what’s kind of happening there?

Roy:  What I’ve been kind of seeing is more of the social costs of change or the emotional costs of change is that when you’re restructuring and trying to adopt the Agile process, there are times when you’re going to have to have conversations in which two people are going to go into the conversation and either one person is going to have to change their way of doing things completely or one of the two has to leave.

I think that’s a very difficult conversation to go into and that’s a significant cost of change that I don’t think a lot of people necessarily think about when they are going in to doing an adoption like this. They are going in to it thinking it’s going to be great, but then, there’s going to be heads bumping and people are going to have to make a decision on if they want to adapt or leave the company or whatever they want to do.

Mike:  We actually do find that there is, and I’m not sure where this statistic came from, between 15 and 25 percent turnover when you start to actually implement any kind of change like Scrum.

Clayton:  Is that because Scrum doesn’t leave a lot of room to avoid the fierce conversations that need to be had?

Mike:  Yeah, you’ve got to have those difficult conversations and some people do not want to do that. It is a significant cost of change.

Clayton:  That’s not even on an individual employee level or the developer level, there are managers that don’t want to deal with that either or that get totally freaked out by having to deal with this conflict.

Mike:  Absolutely.

Clayton:  That’s something I hear, “Oh, we’re fighting all the time. It’s horrible. We used to get along. Why is all this happening?” It’s really that you weren’t really getting along, but everything was so shallow and surface level, that there was really no room for conflict. Now that you’re digging in and really trying to work together and get better, that’s where you’re starting to uncover a lot of this conflict.

Mike:  Yeah, like when they’re going through that whole Bruce Tuckman model of forming, storming, norming and performing.

Clayton:  Yep.

Mike:  A lot of times, organizations are stuck in storming and it’s just normal.

Mike:  Yeah.

Jade:  They shy away from the storming and they don’t just push through to get to the norming part of it.

Clayton:  I think a lot of times, they don’t even realize that they are in the storming.

Mike:  Exactly.

Clayton:  One thing, Jade, that you’ve mentioned before is that, you kind of gave an anecdote about, the company wanted to adopt some Agile principle, but they couldn’t get their risk management software to work with the new way of doing things. I would imagine that there are a lot of companies out there, big and small, that have invested a significant amount of time and money and resources into getting some third party tools or processes or anything like that.

How do we deal with, when we say, “Well, we’re going to get this new process. This new Agile process,” and that makes, maybe it invalidates or makes this other thing you’ve already spent a bunch of time and money on not effective or useless?

Is that something that you think would be a total barrier? A no go?

Jade:  I think that’s pretty scary for a lot of people, not even just in the software and the tools, but there might be entire departments that need to completely change. So if you have the QA department and the PMO and risk assessment and all of these people that are in these gigantic silos and now, you’re telling me that they all need to be cross‑functional and I need to completely change the structure of our organization to deal with that. That’s a terrifying thing to deal with. Especially, to not know what the outcome of that will be.

Mike:  On of the ways to really help get around this is to make sure you have some executive fire cover that is able to say, “OK, you know what, it’s a sunk cost. Let’s just do it and move on.” Because, you can’t really have that at like, especially the large companies, the director levels that are really competing against each other versus the vice presidents who have more of the strategic look. You need somebody high enough to go and say, “Let’s do it,” and make the call.

Clayton:  In your experience, Mike, how often are you seeing that happen where somebody is bold enough to really give the teams enough runway and enough cover to at least attempt a successful change or implementation of Agile?

Mike:  Very few. A lot of is really that at the highest level, they don’t really buy into it. So that could be a whole other conversation.

Clayton:  That’s a good segue into the next podcast. I say thanks to everyone. I’m going to stop now.

Jade:  Thank you.

Mike:  Thank you.

Clayton:  Thank you.