The Cost of Change When Implementing Agile with Mike Vizdos

Episode 17

June 01, 2011

16:18

TBD

tbd

The Agile Weekly Crew and Mike Vizdos discuss cost of change when implementing Agile.

Episode Notes

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 nee