All About Agile | Agile Development Made Easy!
Team member doesn't want agile
I have an influential team member who is uncomfortable unless everything is fully defined up-front and thinks agile is a fad that doesn't really work. Has anyone else had a similar problem and what have you done to overcome it?
Views: 10
Replies to This Discussion
-
Permalink Reply by Ilja Preuß on -
Take a look at http://dhemery.com/articles/resistance_as_a_resource/
-
Permalink Reply by Chris Davis on -
I think every team in transition have encountered this issue, the only why to demonstrate the successes agile can bring is to actually go ahead with an agile project (or as agile as it can be) - somepeople have to be shown agile in action before they can realise its benefits, if they dont see it then - time for them to move to a non-agile team/company!
-
Permalink Reply by Kelly Waters on -
Hi Johnny. I wrote a blog post some time ago to help someone who had an issue like this:
What If An Agile Team Member Won't Play Ball?
It doesn't really tackle the issue of selling agile, but does provide some basic HR/management advice on how to handle a situation like this. Apologies in advance if it's teaching you to suck eggs, but just in case it helps...
Kelly.
-
Permalink Reply by Johnny Dorago on -
Thank you all for your responses. Sometimes he is just outright negative, so the management advice is useful. I guess we might just have to try it and hope he comes round. My worry is that he might just look for any evidence that 'proves' he is right.
Johnny.
-
Permalink Reply by Robert Sfeir on -
If he is looking for evidence to prove him right, then I would preempt that by asking him... Hey [John] how would you approach this, then translate his approach into your methodology. Include him, don't exclude him, and make him feel like he is part of allowing this team to make the transition. I believe Covey said it best: First, seek to understand, then be understood.
-
Permalink Reply by Stavros Pitoglou on -
Nobody can claim to have definitive answers to such complicated questions. For what it's worth, I can tell you what I would do if I were in your shoes:
1. Make sure that the company/organization stands by your side in the decision to go (or try to go) agile. Explain the pro's and con's, 'sell' the decision to your bosses. There is always the possibility of adoption failure, and you can't afford to take that risk on your own (especially if there is someone with a baseball bat behind the corner).
2. Find and present in public agile success stories, making an underlying but clear statement "Agile has been adopted successfully and has produced great results in many cases." Provide the team with undeniable data which prove that any 'a-priori' aphorism has poor historical and scientific background.
3. Come up with measurable targets so that if your plan works, you will be able to confront any skepticism with undeniable facts.
-
Permalink Reply by Robert Sfeir on
-
For #1... I work for a company that has its teeth deeply sunk into SIX SIGMA, CMMI-3 and 4... Trying to tell them hey I have an idea let's go to Agile and here is why won't make one wee bit of a dent. The way to do it is to slowly just start transforming your team to agile one step at a time, all while maintaining the information that the company needs to comply with their current standards. No one has to do Agile in one shot, changing to agile over night is a mistake. You need to implement things one step at a time and allow your team to digest it. If your team is efficient and has proven to show increased productivity and communication, your company will never fight with you regardless of what you call your process.
jmho
-
Permalink Reply by Stavros Pitoglou on
-
Hi Robert.
There can be no objection that, in the vast majority of cases, the progressive approach you describe is the best one to follow. But I think that the problem at hand, described as "an influential team member who is uncomfortable unless everything is fully defined up-front" takes us to the very core of agile management which can be (roughly) defined as "nothing (more or less) is fully defined up-front". I believe that the profound contradiction does not allow any progressive workarounds.
As far as it concerns #1, of course the right paths one can take are more than one. It critically depends on the nature of the company and it's organizational structure.
-
Permalink Reply by Robert Sfeir on
-
I don't completely disagree, particularly with your assessment of Agile's definition, however, everyone has their threshold of comfort as to what is described and defined. In that case why not work with that person to help them define as much as they're comfortable with for the user story / issue / task they're assigned. It separates their anxiety of needing everything defined from the ability of the rest of the team to function in a more agile manner. In that case, the issue assigned would be broken down into sub tasks which would involve things like requirements gathering, design, use case, code, unit test (though I preach TDD it's not possible to push that in this case just yet), QA, deploy. Instead of telling the person here's a user story, now just go make its validation pass with your code, you can break it down in a more finite way for that developer. It just means that developer won't be as efficient as anyone else, and by not being efficient they will feel like they may be doing something wrong. That would cause one of 2 things: Either they'll realize that maybe they need to adapt, or go complain to management. In either case I think it's a win win, because regardless how much influence someone has, showing management that the rest of the team is x amount more efficient than his method, would refute anything that person has to say. Further, by proving things work with the rest of the team, should mitigate any long term issues you have with that person.
I'd never let one person run my team no matter how influential they are. Control your area of responsibility, and the rest will fall into place. Believe me, I'm not living in lala land, I've had some very difficult personalities that tried to cause issues, those people are simply no longer on the team.
R
-
Permalink Reply by Robert Sfeir on
-
I had a similar problem, a slight difference in that the person didn't understand agile, and didn't understand why we had to change anything. That type of problem is most difficult when you have an established team, you recognize that the team is not efficient as it could be, and from your personal experience as a team lead, you know that agile will help shift efficiency and increase communication among team members (of course along with the rest of the benefits such as user feedback, client being happy etc...).
The first thing that was hard was to get everyone to do a stading SCRUM... and I mean literally standing up. I got a lot of ho hums, but when the team saw that the meetings were between 8-10 minutes, folks stopped complaining.
The next step was for folks to notice that during SCRUM issues were brought up, quick one on one meetings ensued, problems got solved and folks started noticing that we made less mistakes because we talked about things more often.
Because of that, the person that wasn't quite convinced started listening. The next step for us was to take the team into more agile planning. The trick there for me was to start asking folks what they wanted to work on. Of course no good engineer wants to be beat at the first cool feature, so everyone jumped in and volunteered to take an issue and work on it. We were still doing the 'how long is this gonna take to do' approach, not quite points.
Next I started discussing with the team some issues with the schedule, discussing why we may be missing targets, and got everyone involved in the conversation. The question was 'well how do you fix this'. I started talking about perhaps looking at velocity over hours of work, that peeked everyone's interest. I shared information I had read in Mike Cohn's Agile Estimating and Planning and used his dog breed example to assign points to issues. There was some resistance of course, but I approached the next 'pick your issue meeting' (which we now call a Sprint planning meeting by asking both how big is this issue, and how long will it take you. The first couple of sprints we did we got a bit more accurate but we still missed the target. But then I suggested we try estimating with points only for an iteration to see what would happen. (I had looked at our velocity going forward and had an idea of points per week already) Of course next iteration was dead on the money in estimation.
Slowly but surely I introduced the various pieces of Agile SCRUM, I even asked if folks would be willing to just pair up for 30 minutes a day just to teach each other what they're working on. Everyone was more than happy to flaunt their skills, but soon enough that broke down into a nice productivity session.
In the end what I'm saying is: Spoon feed it. Bring it in one step at a time. DOn't call it Agile until it's completely necessary. Introduce the concepts as methods of improving team efficiency. Prove your worth, prove your knowledge, use the rest of the team to make the person resisting feel like they should join in or they're just going to be a grumpy bastard. Break it down slowly and certainly don't try to do it over night. Too me 3 months to change how we work, and we're still improving. The advantage is any new person coming in will now just know that we work as an Agile team and resistance is non existent.
(That was long winded but without examples I couldn't clearly sum it up :) )
R
-
Permalink Reply by Kevin Johnston on -
A bit of an extreme view here but if he is so influential but has not the foresight, openess of mind or experience to realise the benefits of agile maybe he is not that good really add its time to let him find his own way..extreme I know ;-)
© 2012 Created by Kelly Waters.
