14

My company has recently switched to an Agile way of working and as a part of it we've started using SCRUM. While I'm very comfortable with it and feel that this way is superior to a traditional one, some of my teammates don't share the same opinion. In fact they are very skeptical about "all that agile stuff", and don't take it seriously. As an example, one of the teammates is always late on the meetings, and doesn't really care about it. The management IMO tries not to notice this (maybe because it's new, and it takes time for the people to get used to it).

My question is, how to address this issue while not raising a conflict inside the team?

Improve this question
5
  • 4
    What's WoW? Googling "agile WoW -warcraft" turned up not much.
    – Joe Daley
    Jan 10, 2011 at 11:36
  • 1
    @Joe - "Way of Working" perhaps?
    – ChrisF ♦
    Jan 10, 2011 at 11:39
  • Way of Working.
    – Sorantis
    Jan 10, 2011 at 11:40
  • Scrum! not SCRUM! WoW? Agile #1 = WoT, not WoW. W/o the WoT, the WoW is just SNAFU. And one of the main ways of thinking is to pull down barriers to communication, not erect new ones.
    – MIA
    Jan 10, 2011 at 22:09
  • 2
    Agile WoW = Raiding a boss or two a night for a week and doing a full clear along the way? And pairing up raiders/doing DPS reviews? Sorry, ex-WoW player here.
    – Wayne Molina
    May 19, 2011 at 12:42

10 Answers 10

Reset to default
21

When faced with extreme skeptism I try a few things:

1.) I demonstrate techniques such as TDD, Continuous Deployment, Pair Programming, Requirements Gathering with your users, short iterations etc. I don't call those techniques Agile or harp on about the Agile Manifesto (I do harp on about Software Craftsmanship - but that's different ;p). I simply show the team members useful tools and techniques that make their lives easier. They tend to hop on the Agile bandwagon once they see the benefits day-to-day.

2.) I don't swap immediately to a full blown SCRUM (or other) methodology. It's always best to introduce small aspects of Agile at a time.

3.) I agree with the skeptics (to a point). Agile isn't a silver bullet and SCRUM, Kanban, Lean etc are also not a silver bullet. Instead I work with them to see what aspects could benefit them immediately (A CI server is a no-brainer usually) and then I trial the rest "Lets give stand-ups a go for one week and then review it".

Like any methodology, SCRUM and others need to actually work with the team and the organisation, not alienate them.

So to get directly to your question. Raise it with the team:

"I'm also a little skeptical about the stand-ups, but I think as a team we should give it a proper go for 1 week (no excuses!) and then review it to see if it worked for us. What do people think?"

Improve this answer
9
  • 9
    @Sorantis - That's not really an Agile WoW problem though is it? It sounds like this team member just isn't good at working in a team! That's more of a human psychology/behavioral issue and the trick to that is generally to find out what motivates that person (both in their positive behavior and their negative behavior).
    – Martijn Verburg
    Jan 10, 2011 at 11:53
  • 4
    ++ When imposed, it's like a religion, and people are naturally resistant. When explored feature-by-feature it's more like common sense, and if people say "but that's basically what we do anyway" then you're winning. I think part of the problem with Agile is simply that it has a name, and therefore comes from without.
    – Mike Dunlavey
    Jan 10, 2011 at 14:33
  • 1
    Ahhh pair programming - that's where 1 guy reads a magazine while the other codes :)?
    – Chris S
    Jan 11, 2011 at 16:10
  • 2
    @Martijn, I've done pair programming where one person has the mouse and the other has the keyboard. That way both have to concentrate ;)
    – Benjol
    May 19, 2011 at 6:52
  • 1
    @Mike Dunlavey: "if people say "but that's basically what we do anyway" then you're winning." -- or perhaps then you're introducing useless beaurocracy? if they do it right anyway then do they really need your rules about how to do it?
    – imre
    Oct 19, 2011 at 12:15
16

A typical case of wrongly implemented Scrum.

Scrum has been imposed to the team. The (whole) team didn't choose it.

When you want to implement it, you must have full support of both the team and management, or it is not going to work at all.

Resistance to change is your enemy here.

I highly suggest you to start over and present Scrum to the team and let them ask questions.

If you fail to sell the idea, don't try to force them using a methodology they don't want. They'll do everything to sabotage it. Coming late in daily stand ups is one of the behavior you'll get.

Please note that Scrum may not advisable for your company. The only persons that can answer that question is the people that work at the base. The team.

Improve this answer
5
  • 1
    Is there a way to make the skeptics to like the SCRUM? It's a bit weak thing to do - just don't use it if you don't like it.
    – Sorantis
    Jan 10, 2011 at 12:33
  • 1
    @Sorantis: there is no easy way to do that. You will have to invest lot of efforts and time explaining how Scrum will provide benefits to them. The comfort of status quo is so important that they'll do everything they can to keep it. Even forcing themselves to not understand the benefits. It's what happen when you impose others your ideas. Your situation is really hard to solve.
    – user2567
    Jan 10, 2011 at 12:40
  • @Sorantis - it happens every day. It's called sales. Just keep pointing out the good things that SCRUM has brought you. Increased communication! Adapting to change! Keeping the project simple! Don't be too good to use Pavlov's work. ;-) People respond to being shown, less so to being told. Show them how well SCRUM is working for you, and they'll follow suit over time.
    – Steve Goodman
    Jan 10, 2011 at 20:07
  • That is what Stalin said.
    – Job
    Jan 11, 2011 at 3:20
  • Stalin said what?
    – user2567
    Jan 11, 2011 at 7:15
5

It may be that the concept of daily meetings does not apply very well to what a person is doing. Those meetings are not free of cost.

If what you're doing requires a lot of long-term concentration, like heavy math, the meetings can de-rail you and be frustrating. I work with someone like that, who prefers to meet on a weekly basis, which is perfectly reasonable.

Improve this answer
5

Actually to be honest if I was on your programming team, I would probably be that sceptic ! I've seen a long line of methodologies that were supposed to revolutionise things and make projects come in on time, within budget, and bug-free. This is just the latest. Why should I believe the snake-oil? 10 years ago the same people were flogging something else, in a few years something new will come along. Don't get me wrong I think some of the new methodologies bring some useful ideas. Unfortunately they bring a lot of dogma and stupid ideas too.

Does it really matter if he doesn't get on board? Just assign him some programming tasks and let him do it the way he wants. If his work is satisfactory let him be. If his work isn't satisfactory, replace him. Why is it so important for people to follow scrum?

Over the years I've seen a lot of good programmers quit or get annoyed because their manager keeps introducing new methodologies. They just want to code and get the job done. Trust me a few years from now you will be cursing scrum, and jumping on whatever the latest fad is.

Improve this answer
1
  • -1. Even if scrum is not here to stay, you are still part of an organization. If that organization decides to move to scrum, then it is very little trouble to move along. If you're a good programmer and team player, and you are willing to accept that somebody else knows more about the commercial priorities, then scrum will exactly allow you to do your work, your way. If done well, scrum should not take more than 10% of your time. In that 10% you have also done your planning and reporting. Boohoo.
    – Kris Van Bael
    Sep 12, 2013 at 3:42
1

If you are doing agile then you should have a backlog you are working from. Use the scrum to hand out assignments from the backlog.

The choice (best) assignments get picked first at the beginning of the meeting. When you late comer arrives just give him what's left for day.

Doesn't matter if he's God's gift to programming, he gets the crappy task no one else wanted. If he tries to steel another task or work on something else the team as a whole needs to lean on him and force him to only work on his "chosen" task. You should probably have a build master that can reject his changes if he is not working on the chosen work.

Also the team should be setting goals and potentially compensation. You can vote as a team to not reward those that are not participating. This does vary on the amount of ownership your management has given to your agile team. Remind management of those that are hurting the team and preventing the team from succeeding.

Remind him that if he shows up on time he can participate in the process.

Improve this answer
1
  • This way you'll lose the last chance of selling Scrum to the skeptics. Imho real problem is imposed methodology, as other answers suggest.
    – MaR
    May 19, 2011 at 9:20
1

Scrum teams are supposed to be self-organizing. Scrum also works by implementing extreme transparency in everything.

So the obvious answer is that the Scrum Master calls a meeting, explains the problem (but don't kid yourself, everyone on the team already knows exactly what the problem is) and then tells them they've got 1 hour to figure out what they're going to do about it. Then he sits in the corner and keeps his mouth shut.

Obviously, this is a team new to Scrum. So the key is that the Scrum Master has to accept whatever answer the team comes up with. If he overrules them, or imposes his own ideas onto the solution he'll destroy the trust the team needs to build with him that they are allowed to self-organize. It's possible that the team will decide to do nothing.

In any event, the issue should be reviewed at the Sprint Retrospective and the efficacy of whatever solution they came up with can be discussed.

Avoiding "team conflict" shouldn't even be a factor at all.

Improve this answer
0

Fire the teammate, then he won't be causing controversy within the team.

Improve this answer
8
  • 1
    I don't think this is a solution at all. It's like, my hand hurts..Oh, let's just cut it.
    – Sorantis
    Jan 10, 2011 at 11:38
  • 4
    It depends - if the company has chosen to implement SCRUM and staff memebers are not willing to work as required by the business then that's fairly classical grounds for dismissal.
    – Murph
    Jan 10, 2011 at 12:30
  • @Sorantis: more like, "if thy left hand offend thee, cut if off", or something like that. And, warn him first.
    – John Saunders
    Jan 10, 2011 at 14:44
  • 2
    @Rob: go through the process, make it clear what is expected of the skeptic, and if he is unwilling to do what is required, either let him leave, or else fire him. Failing to do that sends the wrong message to the rest of the team - that SCRUM doesn't matter, and that they can all ignore it, just like the skeptic.
    – John Saunders
    Jan 10, 2011 at 15:24
  • 2
    Agile is about the team. If you have someone that is refusing to be part of the team then management needs to put them on probation or let them go. In the long run you will be better with a smooth running team that with someone causing trouble. I have heard many stories of agile teams destroyed by one bad apple.
    – Bill Leeper
    Jan 10, 2011 at 16:58
0

Browse through your older work, dig up multiple examples how the water-fall approach let you down many times in the past. Then present the cases to your team mate. With a glimpse of common sense, he will see the light.

Programming is a precision activity so a rare individual would stay unreceptive to the hard facts. At least, in theory.

Improve this answer
4
  • The thing is that I'm a new employee in the company. I came when they've started using agile WoW. And my teammate works in the company for 15 years
    – Sorantis
    Jan 10, 2011 at 11:40
  • 2
    I just misread "water-fall" as "water-fail" and it was the best renaming of a development approach I have ever seen. Awesome!
    – glenatron
    Jan 10, 2011 at 13:01
  • @glenatron: Very nice, really hits the nail.
    – user8685
    Jan 10, 2011 at 13:53
  • 3
    The problem with the approach of digging up counter-examples is they are not good arguments in favor of other specific ideas. Nobody likes water-fall, but that doesn't mean they want to get on board with Agile.
    – Mike Dunlavey
    Jan 10, 2011 at 14:26
0

Who made the decision to switch and why? Where those skeptics in on the decision at all or was the decision just dropped on them?

Are you being too rigid and/or fast in your implementation of your new methods? Did you put out good (not necessarily perfect) products using your old methods? Have you demonstrated to the skeptics how it will benefit them? Can you demonstrate it? Have those that have "seen the light" demonstrated the skeptics how it benefits them, the team and the company?

Probably you are asking them to accept everything only on the word of the believers. More than likely these skeptics have taken up new methodologies before and no benefits where ever realized.

Maybe you could do a project or two with only the believers working on it using your new procedures. Take real measurements and demonstrate to the skeptics real benefits. Maybe even set up a little competition between the skeptics and their old ways and the believers and their new ways.

Of course then what do you do if the skeptics win?

Improve this answer
1
  • I'm not a manager, I'm just a team member. The decision has been made by management
    – Sorantis
    Jan 10, 2011 at 15:34
0

Have a team meeting to discuss and figure out why your company switched to SCRUM and get everyone to identify what they think about SCRUM would add value to the current mode of operation. Sometimes companies do make boneheaded switches (I have been in scrum meetings where nobody really listens and everyone just rattles off what they did yesterday and leaves. These teams usually reach an equilibrium like - "I won't question you and you don't mess with me" and waddle there. That is just a waste of time), So take what's best for you.

Veterans usually have a lot of resistance to anything that might change their current style of working, So you have to ensure there are enough carrots for them to get off their inertia. In this case, I would either have a 1:1 with that person or make him the scrum master :). Once you give them responsibility, they will find peace with it or do away with it completely because it is not adding value. Both are win win.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.