Advice Needed for Difficult Developers

[Anita]

I really need some advice. On my current project with an oil and gas
client in Houston, I am having extreme difficulty from the developers
on my team. Most of them having never used any software development
process. In their previous projects (4 of them), they were given
requirements, put in a room, and then developed code on their own.
There is one developer, the 5th, who worked at another oil and gas
company for 2.5 years. He knows the Scrum process used at Chevron.

That former oil and gas developer joined the project about 3 weeks
ago. I joined the project about 1 month after the development start;
I've been on this project for about 2 months. I was hired to act as
the ScrumMaster for the development process.

All of the developers are VERY combative and VERY unprofessional and
VERY rude. I have tried different ways and hybrids to buy-in from the
team on a process that will work for this project. They say that they
want to use Scrum, but they for some reason are they are behaving this
way.

The team completed a phase 1 implementation using a hybrid approach.
However, for this next phase, due to the amount of detail in the
requirements and backlog, the Scrum process needs to improve.

Have you ever experienced this? How have you implemented Scrum in
such a difficult environment?
Any guidance and advice you have is GREATLY appreciated.

[Mark Levison]

Anita - I think we will need understand the people a bit more. The key here is to understand their needs and what they gain from their current approach. If you want people to change the first trick is to understand where they come from.

Cheers
Mark Levison

		Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQ Blog | Twitter | Office: (613) 862-2538 Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

[will jessup]

Anita,

The problem could arise from a million places so I won't guess as to what those are, however, developers are typically bright, logical, people. If they don't understand the need for any one piece of a process, the entire thing will be scrapped - so when we first were jumping into SCRUM our scrummaster started by telling us all the problems we were going to solve w/ this process that would make our lives easier, the clients lives easier, the product better, etc. 

Developers won't accept "just do this because I say so". 

Imagine the dialogue:

"ok we're going to do estimates for these cards"

"why? i hate doing estimates"

"Do you have a better way of getting the client information about our best estimate for how long this project is going to take? without this we can't get the budget approved and nobody gets paid."

"hrm... no"

"so if we do this estimate we'll have our complete bs, total guess, estimated timeline based on a bunch of stuff we know will change - but at least it is something."

"ok =]"

and so forth for each part of the process. 

Will 

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

--
Will Jessup
Managing Member
760 807 0850

Citrusbyte | Modern Web Development
www.citrusbyte.com

[Kevin Shine]

Instead of thinking of getting people to buy-in (like you are selling something and they should buy it), try to think of trying to get people to enroll in the process. There is a big mind shift between these 2 thinking approaches. One is collaborative and cooperative and the other is more command and control.

The bottom line is developers are sick of people trying to sell them something, and they believe that they know the best way of doing something, as they are doing the work. ....that's not so far from the truth.

You need to find a way of becoming part of the team and get them to see you as a servant of the team rather than a controller. That's not going to be easy because of everything that's happened to them in the past.

The bottom line is you need to let them know that they are in control and you are simply an advisor.

Advising people and letting them come to their own conclusions is way different from telling them what to do.

From my experience, depending on the people involved the transformation I am talking about can take months or over a year to achieve.

"You can’t force change on people. Instead, show them how the future might be and help them participate in creating it."

[Gustavo Cebrian Garcia]

Hello,

 

This is the strategy I use ( apart from being a really good psychologist and all those things you have already mentioned).

 

1-Use the intelligent question "Why not?" "  ( It is proven by studies it works )

 

Anita: "Let us use the planning poker technique and do relative size in points which is a proven way to do things in a productive way"

 

Martin: "No, no, no, it does not work"

 

2 Get on his/her side

and you say peacefully and quiet 

 

Anita: "Why not Martin? Did you have any problems, I heard people having problems, to be honest. What do you think we should do?"

( At this point, you are on the same side of the river "What do you think WE WE should do", but the problem is there to be investigated by Martin )

 

Martin "Well, we tried it and it did not work."

 

Anita "What should we do then, Tell me your experiences, I want to learn from you"

 

( Then, Anita asks more questions to really understand why it did not work )

 

3-Make references to forums, books, studies, conferences, and ask him to find documentation why it did not work ( in a nice way )

 

Anita: "Really?!, I understand, I understand. I will tell you something. why do not we spend five minutes doing some research on proven cases and do some reading. Let us google if you like, maybe we have to exactly define what story points and planning poker mean, let us check some forums, books, studies..., if we find documentation which says it does not work, maybe we will have to do some different proven technique.

4- He did not fail

 

By saying this "maybe we have to exactly define what story points and planning poker mean", he will not think he failed.

 

Once you he finds proper articles...

 

Anita: "Maybe you can apply this in a different way, I am sure you are intelligent enough to get different results"

( never mention succeed or failing, this is just a different way to get different results )

 

From now you tactfully are making him think in another way. The developer will not say no to reading ( I hope ), and I am sure that he will understand more when he does his own reading.

 

There is not war of feelings, no failing, no succeeding, I am going to do things in a different way.

 

This way you do not create a war, and he will not think he failed ( as I said earlier )

 

( I make the mistake once of saying "You did not make it work!!" -->  wrong, we want to be on the same side of the river)

 

Hope that helps. ( I will add this to my blog )

 

Anita, LET US KNOW !

 

Gustavo Cebrian-Garcia

[Alan Dayley]

Anita,

Can you please clarify for me an important point. To me it's not
clear from your original post the scope and focus of the problem.

Are the team members "VERY combative and VERY unprofessional and VERY
rude" about Scrum or about the team or about the work? Are they
behaving this way to each other or just to you or to whom?

Alan

[Bachan Anand]

Anita,
Glad to see another thought provoking question.

On Nov 16, 2010, at 4:51 AM, Anita <dabai...@gmail.com> wrote:

> I really need some advice. On my current project with an oil and gas
> client in Houston, I am having extreme difficulty from the developers
> on my team. Most of them having never used any software development
> process. In their previous projects (4 of them), they were given
> requirements, put in a room, and then developed code on their own.
> There is one developer, the 5th, who worked at another oil and gas
> company for 2.5 years. He knows the Scrum process used at Chevron.
>
> That former oil and gas developer joined the project about 3 weeks
> ago. I joined the project about 1 month after the development start;
> I've been on this project for about 2 months. I was hired to act as
> the ScrumMaster for the development process.
>
> All of the developers are VERY combative and VERY unprofessional and
> VERY rude. I have tried different ways and hybrids to buy-in from the
> team on a process that will work for this project. They say that they
> want to use Scrum, but they for some reason are they are behaving this
> way.

Why do they say they want to use Scrum?

>
> The team completed a phase 1 implementation using a hybrid approach.
> However, for this next phase, due to the amount of detail in the
> requirements and backlog, the Scrum process needs to improve.

Does the team feels any improvement is required ? Could you please clarify what you mean by Scrum process need to improve ?

>
> Have you ever experienced this? How have you implemented Scrum in
> such a difficult environment?
> Any guidance and advice you have is GREATLY appreciated.

Any change is hard and I experience it with Scrum implementation and in other areas as well . As others have stated for anyone to be change agent . Either you need to gain trust and respect or you need to team up with other in the org who already have trust and respect of the team . How does that apply in your current situation.

Good luck and looking forward to your success as a ScrumMaster

[Divakar Singh]

To me it is interesting to see:

"All of the developers are VERY combative and VERY unprofessional and VERY rude. "

I have heard this kind of statements from Scrum skeptics, not from believers :-)
May be Anita would like to give some examples why she thinks like that.

"I was hired as Scrum Master" is also somewhat strange statement to me.

Best Regards,
Divakar.

[andrej...@gmail.com]

" Most of them having never used any software development
process. "

Are these guys professionals? IMHO, Problem is not in scrum here, but
in people who used to work in their own way.

i would start hiring a new professional team.

Andrej
www.agilemindstorm.com

[LESLIE SCANTLING]

Anita - my 2 cents....
 
I have been in organizations where I was discounted as a scrummaster and developers barely gave me the time of day when it came to Agile implementation and am now fortunate to be at a company where I command respect because Agile is respected and we have willing and eager participation in the proceedings and improvements.  I can very easily point to the difference in the two situations:  management.  If Agile is respected as a framework by top management, then the developers are much more likely to adapt.  And where I am currently, management has a ton of respect for the scrummaster role as well.  If you are not supported and empowered at that level, then you are pushing a boulder uphill.  It definaitly needs to be a full company buy in for an Agile model to be effective in my limited experience.  So, in dealing with embattlement from developers, what does your management do to train and communicate surrounding the value of the framework, etc?  Just a small piece, I know (and sorry for any generalizations), it is just one aspect I wanted to share from my experience. 
 
> Date: Wed, 17 Nov 2010 06:15:15 -0700
> Subject: Re: [Scrum] Advice Needed for Difficult Developers
> From: ada...@gmail.com
> To: scruma...@googlegroups.com
> CC: dabai...@yahoo.com

[Ashish Mahajan]

Scrum is a tool.

Not  a goal.

Scrum can help you reach your goal.

I think the team  lacks the urgency to move to Scrum.

Instead of Selling Scrum , sell its results.

1-0-1 coaching may help , as in a group real cause might not come up.

Use the technique of 5 Whys...

May be there are other dysfunctions , which Scrum surfaces very fast..

Does the management believe in Agile ?

Did using Scrum benifit the team in last 2 months ?

Is the team self Organized?

I believe Scrum surfaces many problems in  a team very fast.

It brings the problems painfully clear.

One of the technique is to follow the retrospective so religiously, and follow it so badly , that the team starts realizing the power of 

Scrum activities.

Sometimes , it is also necessary to hear the grudges of people.The may be right.

Ashish

[Ashish Mahajan]

Hi LESLIE  ,

I totally Agree with you ..

[Danielle Bailey]

Thanks everyone for your input, guidance, and advice. :-)

I have previously tried as expressed above various collaborative, conversation, and discussion tactics for the developers to accept and embrace Scrum.  I was told during my interview that the developers actually went to their executive management stressing the need for a ScrumMaster to implement Scrum.  I'm wondering now if that was true.  My company doesn't not have any formalized Scrum training.  The training that the project team ahs received has been gradual through the project process.  I was told by management and the developers that they knew and experienced the Scrum process, which I know realize they truly had not.

 

I am a true believer of Scrum.  I got my certification so that I could learn more about Scrum and its value not only in software development.

 

I did hear on earlier this week that most of the developers for up to 10 years were given requirements from a managers and sent to a room to figure things out and develop own their on.  Although I have inquired about they previous experiences on projects, they have been very tight-lipped and closed-mouthed.

 

I found it interesting that the major complaint is the daily stand-up meetings.  The developers would not be forthcoming about goal and impediment status; they would race through their goals for the day to complete the stand-up in 5 minutes without any clarity or substance.  I quickly began to see a lack of accountability.

 

I do believe an aspect of psychology is a factor.  It may be how some people say that they want to grow and evolve, yet they fight strongly against letting go of accustomed habits.

 

I also take this as an opportunity for me to grow professionally and personally.

Thanks again and wish me luck as I continue to embrace the Scrum process! :-)

 

Anita

[Ashish Mahajan]

Hi Danielle ..

This is what I can say ..

   "Woods are lonely dark and deep,

    But I have promises to keep , 

    And Miles to go before I sleep,

    And Miles to go before I sleep...." 

All d Best for evangelizing Scrum...

Scrum is a tool..Not a goal ..

Ashish

[George Dinwiddie]

Hi, Anita,

On 11/16/10 7:51 AM, Anita wrote:
> All of the developers are VERY combative and VERY unprofessional and
> VERY rude. I have tried different ways and hybrids to buy-in from the
> team on a process that will work for this project. They say that they
> want to use Scrum, but they for some reason are they are behaving this
> way.

This is not a process problem, but a people problem. I don't understand
the context and the behavior you're seeing well enough to make specific
suggestions, but I can offer some general advice.

Try to understand their behavior from their point of view. Don't
understand their point of view? Ask yourself, "what would they have to
believe for this behavior to seem reasonable?"

Check out Dale Emery's "Resistance as a resource"
http://dhemery.com/articles/resistance_as_a_resource/ as well as his
other articles and blog.

Give them effective feedback on their behavior. Esther Derby describes
patterns for giving feedback that I've found so helpful that I keep a
list (http://idiacomputing.com/moin/GivingFeedback) of my favorites.
You'll find lots of other helpful stuff on her blog, also.

- George

--

----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Mark Levison]

Anita - one more thought. It is difficult if not impossible to sell people on ideas, instead its better to listen. Ask people questions that seek to understand the problems they have, not their problems with Scrum, but their bigger problems. Use Scrum to help them solve those problems and they will discover its value far faster.

Also to add to George's list, I suggest you look into a neuroscience modeling tool that will help you understand why another person is acting in certain way. The model is called SCARF and is described by David Rock in this paper: http://www.your-brain-at-work.com/files/NLJ_SCARFUS.pdf  - rather than try to summarize I will just say that its one of the best tools I've found in the past few years.

[Mark Levison]

Gustavo - I love the basic ideas of this advice but am troubled by some specifics.

On Wed, Nov 17, 2010 at 5:15 AM, Gustavo Cebrian Garcia <g.cebria...@gmail.com> wrote:

Hello,

 

This is the strategy I use ( apart from being a really good psychologist and all those things you have already mentioned).

 

1-Use the intelligent question "Why not?" "  ( It is proven by studies it works )

Why is a potentially dangerous question, there is a high likelihood that it put the person being asked on the defensive. Asking What/When/Where questions help us achieve many of the same ends without the defensive reaction. Instead of "Why not", try "What do you think won't work with planning poker" or "Can you tell me what you think the problem is". We move the focus from the person to the problem.

 

2 Get on his/her side

and you say peacefully and quiet 

 

Anita: "Why not Martin? Did you have any problems, I heard people having problems, to be honest. What do you think we should do?"

( At this point, you are on the same side of the river "What do you think WE WE should do", but the problem is there to be investigated by Martin )

 

Martin "Well, we tried it and it did not work."

 

Anita "What should we do then, Tell me your experiences, I want to learn from you"

 

( Then, Anita asks more questions to really understand why it did not work )

This is another great technique but you must be very careful to be genuine. If the person has any reason to think you're not this approach can backfire. Again its all about the questions.

...

Many other good suggestions

Cheers
Mark

[Mark Levison]

BTW here is a picture of the SCARF model:

From a good summary of the model: http://www.edbatista.com/2010/03/scarf.html

Good luck

Mark Levison

		Mark Levison | Agile Pain Relief Consulting | Agile Editor @ InfoQ Blog | Twitter | Office: (613) 862-2538 Recent Entries: Self Inflicted Agile Injuries, Why use an Agile Coach

[Gustavo Cebrian Garcia]

Mark,

 

Those are the principles, you need to do it carefully.  :-)

 

Gustavo.

--

[learnerplates]

Anita,
I have a similar problem.

We've been scrumming for the past couple of years and I as a
scrummaster am still getting resistance from at least one developer.
The developer has about 20yrs experience and has been in many
processes. he doesnt believe in Scrum, even though he attended the
same training as myself and the rest of the team.
consistently underestimates and then promises tasks will be complete
by lunchtime, they very rarely are, usually this continues for a
couple of days. I believe this is due to the lack of respect for scrum
and the dishonesty is a method of disrupting the process.
Weekly arguements over the usefulness of scrum and how it demeans the
engineering process by trivializing the technical tasks.

How can a scrumaster overcome this?

LP

[Ron Jeffries]

Hello, learnerplates. On Tuesday, January 4, 2011, at 8:29:45 AM,
you wrote:

> How can a scrumaster overcome this?

Here is some advice that Kent Beck gave on this topic:

1. Sit down with the developer and explain the impact of his actions
on the team. Ask him to improve.

2. If no improvement, sit down with the developer and explain again
the impact of his actions on the team, and the impact on himself if
he does not improve.

3. If no improvement, implement the impact described above.

If I were convinced, as you seem to be, that this developer is
sabotaging the process, I'd discuss it with him at length. If the
behavior continued, I would remove him from the team.

Ron Jeffries
www.XProgramming.com
Now -- Bring me that horizon. -- Captain Jack Sparrow

[nela]

Hi everyone, from a scrum master that once was - Long time no see !!
As I had my fair share of disruptive team members... ... ...
Two disruptive and non-cooperative developers existed also in my team
some time ago, and when I suggested to the team that we continue
without them, they willingly left with a sigh of relief. (One of them
left the whole company after he used up his holiday time). However -
and this is very important - it did not improve the teams performance.
The team is now steady but slow. They wanted another scrum master,
they got the one they wanted, but I from the outside do not see the
improvement. There is one, sorry - they dont argue any more. They
enjoy. It is like they reached the speed of how they want to work,
they seem to be self-organising, but they are terribly slow. They have
already been working on one web-application for about 1 year, and just
now "promised" they will finish by the end of 2011. That is 2 years.
For me, as a project manager, it is still hard to believe they will
ever finish. But I had to put something on paper and it was accepted
by managers... And if I do not believe in the team, who will ? The
logical answer would be: they believe in themselves. But, looking from
the outside - they are just passing the time and doing their 8 hours
work waiting for the next holiday time round the corner.

To get the managers to accept prolongation and increased effort, is
easy, compared to trying to really believe that this application will
be up and running by Nov.2011 so we can all enjoy Christmas2011 !!

So, to come back to the subject : from this experience I can say -
removing a disruptive team member from the team may make the team
happier, but it may not make them more efficient.

Nela.