Scrum: Resistance is (not) futile

Question

I'm the second dev and a recent hire here at a PHP/MySQL shop. I was hired mostly due to my experience in wrangling some sort of process out of a chaotic mess. At least, that's what I did at my last company. ;)

Since I've been here (a few months now), I've brought on board my boss, my product manager and several other key figures (But mostly chickens, if you pardon the Scrum-based stereotyping). I've also helped bring in some visibility to the development cycle of a major product that has been lagging for over a year. People are loving it!

However, my coworker (the only other dev here for now) is not into it. She prefers to close her door and focus on her work and be left alone. Me? I'm into the whole Agile approach of collaboration, cooperation and openness. Without her input, I started the Scrum practices (daily scrums, burndown charts and other things I've found that worked for me and my previous teams (ala H. Kniberg's cool wall chart). During out daily stand up she slinks by and ignores us as if we actually weren't standing right outside her door (we are actually). It's pretty amazing. I've never seen such resistance.

Question... how do I get her onboard? Peer pressure is not working.

Thanks from fellow Scrum-borg,

beaudetious

Answer 1

While Scrum other agile methodologies like it embody a lot of good practices, sometimes giving it a name and making it (as many bloggers have commented on) a "religion" that must be adopted in the workplace is rather offputting to a lot of people, including myself.

It depends on what your options and commitments are, but I know I'd be a lot more keen on accepting ideas because they are good ideas, not because they are a bandwagon. Try implementing/drawing her in to the practices one at a time, by showing her how they can improve her life and workflow as well.

Programmers love cool things that help them get stuff done. They hate being preached at or being asked to board what they see as a bandwagon. Present it as the former rather than the latter. (It goes without saying, make sure it actually IS the former)

Edit: another question

I've never actually worked for a place that used a specific agile methodology, though I'm pretty happy where I'm at now in that we incorporate a lot of agile practices without the hype and the dogma (best of both worlds, IMHO).

But I was just reading about Scrum and, is a system like that even beneficial for a 2 person team? Scrum does add a certain amount of overhead to a project, it seems, and that might outweigh the benefits when you have a very small team where communication and planning is already easy.

Answer 2

I think the key would be to help her understand why you are doing Scrum in the first place. I guess you have your reasons, so why not tell her? You are likely to get resistance towards any change if the people involved don't understand why there is change or what they will benefit from it. If you can explain your reasons for using Scrum, and the following benefits, to her in a way that relates to her everyday work, I think she is more likely to adapt a more positive attitude towards it.

If she sees no value in the Scrum process, or doesn't understand how it relates to her, she probably won't care about it.

I think one of the most important concepts for someone to understand regarding Scrum is the fact that you are working as a group and commit to your project as a group, not as individuals. For many people, this is the hardest thing to grasp, since they are so used to living in "their own World".

Answer 3

She may not understand scrum or even have any interest in changing the way she works. Did you talk to her about scrum and her thoughts on development methods before starting to use scrum methods? It sounds like you think it is the right approach and are forcing it on her without considering her input or her concerns.

Answer 4

But I was just reading about Scrum and, is a system like that even beneficial for a 2 person team? Scrum does add a certain amount of overhead to a project, it seems, and that might outweigh the benefits when you have a very small team where communication and planning is already easy.

One of the big benefits of Scrum is the communication between the developers and the stakeholders (users, product managers, etc). The stakeholders get a high degree of visibility into the current state of development and there is a tight feedback loop with development so that priorities and requirements can be shifted around very quickly if necessary.

From that aspect of things, Scrum can be very useful even with a single developer.

If you have already tried to explain the benefits of Scrum to her and she's not even willing to give it a fair try, then I'm not sure what more you can do other than get your manager to impress upon her how important it is to get on board with this process.

Answer 5

levand, "17 of 26" hit the nail on the head as far as why we are attempting to use Scrum principles in such a small shop - providing some transparency into where we are in the development cycle. Previously, things sort of got done when they got done and they couldn't ever tell their customers when a new release (of a purely web application) would come out and address their bugs and issues. Now we know, that the next release will be 9/15 and we are on track to meet it. Needless to say, the stakeholders are psyched!

Jim and Anders, I may have been a bit blunt in my assessment of the situation. When I was hired on I talked alot about Scrum and how I used it at my previous gig. We spent alot of time in the 2 interviews talking about it. My colleague just sat there with a blank look showing no interest whatsoever.

In my first few days, I tried to discuss her current approach to development and she didn't open up. I offered to let her read my books on Scrum if she was interested - which she still hasn't. One of my books has been read by 3 stakeholders already - just not my colleague sadly.

I once read the best way to implement scrum is not to study it to death, but just start doing it one way or the other. That's the approach I've taken here.

I'd still like to get her on board somehow. I think me taking the time to shape up our bug track/issue practices and the like will help her out in the long run and she sees that.

I should mention that my colleague is a bit of an emotional wreck and is very unhappy I was hired. That is probably the biggest barrier to any change I suggest. :)

Thanks,

beaudetious

Answer 6

Simple. Don't talk about scrum. Don't use scrum on her. Instead take the underlying principles of scrum (e.g. the purpose as opposed to the application) and create different approaches that accommodate her way of working but have subtle tints of scrum.

All humans are different and a lot of programmers dislike scrum. I wouldn't force it upon them as that would just be counter-productive. I'd suggest identifying the problems in the development process (in a non-scrum fashion), see if you can get her to agree that the issues exist, then ask her what she thinks would be a good solution. Her co-operation and input into the process is essential to her co-operation, if she doesn't have buy-in she wont become a citizen.

From there on in you can hopefully create some sort of quasi-hybrid scrum + her approach to the process where you can both agree on the way forward.

Answer 7

Without her input, I started the Scrum practices (daily scrums, burndown charts and other things I've found that worked for me and my previous teams (ala H. Kniberg's cool wall chart). During out daily stand up she slinks by and ignores us as if we actually weren't standing right outside her door (we are actually). It's pretty amazing. I've never seen such resistance.

Question... how do I get her onboard? Peer pressure is not working.

Yikes! Who would ever want to work in such an oppressive environment? If you're lucky, she's sending around her resume and you'll be able to hire someone who is on board with your development process.

Assuming you want to hang on to her, I'd turn down (or off) the rhetoric and work on being a friend and co-worker first. If the project is a year late, she can't be feeling good about herself and it sounds like you aren't afraid to trumpet your success. That can be intimidating.

I know nothing about Scrum, however. I'm just imagining what it would be like to walk around in your co-worker's shoes.

Answer 8

Continue your efforts to involve the other developer. Remember you are the one who wants to make this change. Ask for help with problems you have. Invite them to the daily stand up meeting. I currently do the planning for the daily stand up and I make sure all the pigs and chickens are invited. If you are the lead on the project it is up to you to address the situation and take a risk. Put yourself out there.

Answer 9

I'm not sure Scrum is the central issue here; I'm guessing she feels threatened by the new guy bringing in a lot of new ideas and stirring things up. I've been in that situation before as the new person bringing in a new perspective on things, and sometimes it's just difficult to immediately bring those existing people around to a new way of thinking. It often requires a culture shift which doesn't happen overnight.

Try to get her input and opinion on things as much as possible, and try to show that you respect that she has been on the team longer than you. If after a while she still doesn't participate, then all you can do is mention it to your Manager and let them take it from there.

Answer 10

Thanks for all of the input. I will tone down my efforts to get her involved in new development processes as well as seek out her opinions on how things should evolve. I've been told I've already helped drag her out of her coding cave she normally resides in since I've been here. This place has never seen collaboration like I anticipate we'll eventually get to. I'll look at this as a professional challenge.

Thanks,

beaudetious

Answer 11

beaudetious, buddy,

I would really suggest you read Steve Yegge's blog called "Good Agile, Bad Agile". It's an oldy but a goody, and I think it's a must read for anyone - like myself about 2 months ago - who gets a little let's say "over-eager" to agile-up their workplace. Agile offers a lot of good practices, but you have to take them all with a grain of salt and adopt what you're lacking and skip out on all the other crud that might be unuseful for a particular situation - e.g. the daily scrum. If your co-worker would just like to code in quiet (read Peopleware for why this is a good thing) and she's being a productive team member quit bugging her with your scrumming a let her work in whatever way she likes most.

People are usually less "hostile" about these practices if you just approach them and simply say "Do you have a sec? Listen, communication is really a problem right now, I feel like I don't know what you're doing and I really don't want to step on your toes again and spend two days writing something you already did like last week, so let's work on this. I'd like to try X, what do you think?". Be compassionate and don't tolerate "bad apples", that's literally how I agiled up my workplace, and many problems have started evaporating. We're by no means an 100% XP or 100% Scrum compliant place, because we just use whatever works and was needed.