Have you heard a developer on an agile team say something like this?
“Agile has too many meetings”
“I just need to get back to my real work”
“Why should I change, the old way works fine”
“It’s not my job to test”
If you’ve heard these, your developers (and possibly their managers) have some resistance to your agile practices.
This has probably led you to ask, “Why are developers disengaged? Why don’t they support this transformation? Why won’t they help us succeed? How can I reach them?”
Combining his experience as an Agile Coach and Development Manager with wisdom from the fields of psychology, communication, negotiation and behavioral economics, David will provide techniques to better understand, communicate with and engage developers.
The session will cover:
Identifying common disengagement and resistance patterns
Insight into the “developer’s mind”
How to get past the surface of resistance and into the root of the problem
Techniques to get developers (and others) off the sidelines and engaged in the process
9. What does non-engagement look like?
Won’t attend meetings
Late to meetings
Unprepared for meetings
Silent in meetings
Very vocal in meetings
Won’t help test
“I’m done with my part”
Won’t swarm
Starting work before other work is
finished
“Working to rule”
Hurrying the process
Superhero complex
Don’t care about the users
11. Developer’s Mind (stereotype alert)
• Strong identity as a developer, driven by degree and years of effort
• Recognized for working independently
• Valued for seeing all the possibilities and coding for them the first time
• Don’t like touching things twice
• Value structure and order, high need for control and predictability
• Problem solvers; like solving puzzles
13. Techniques
• Look beyond the initial problem
• Usability studies
• Fist of 5
• Retrospectives
• Look for the bright spots
• Give feedback
• Clarity of purpose
• Misc. techniques
14. Treat them like users...what
they ask for isn’t what they
really need
15. “Agile has too many meetings”
• It’s not about the meetings
• It’s about (protected) uninterrupted work time
• To fix this complaint, protect your developer’s focus
• Without adequate focus, they will be frustrated
16. Usability Studies
• “Show, don’t tell”
• Seeing people struggle speaks directly to the
elephant
• If their elephant cares about the end user, everything
else falls into place
• Also, pair with customer support/implementation
18. Retrospectives
• Look here first
• Allows for self-healing teams
• When was the last time your developers suggested a
change that was implemented?
• Consider a “check-in”
19. Clarity of purpose
• If you ask, “What is the purpose of this meeting?”,
what would your devs say?
• “What is a successful sprint”?
• “How can you help the team be more successful 4
iterations from now?”
• They may be moving, just in the wrong direction
20. Find the bright spots and give feedback
• Focus on what works and reinforce it
• Assume they don’t know which behaviors are
beneficial
• Situation, Behavior, Impact (SBI)
• Look at technical practices as well
• 5-1 ratio
21. Misc. techniques
• Lower your WIP
• Diff your environment
• Experiments
• Sit facing the problem
• One-on-ones
• Ask “What if they’re right?”
• Guilds/COEs
• Remind them how far they’ve come
22. Conclusion
• Motivate the elephant
• Protect their focus
• Usability studies for engagement
• Focus on what is working and reinforce it
25. Bibliography/Additional Reading
• Elephant and Rider – The Happiness Hypothesis, Jonathan Haidt
• Elephant and Rider applied, Bright Spots, etc. – Switch, Chip Heath and Dan Heath
• Identity, decision making, etc. – Predictably Irrational, Dan Ariely
• Negotiation – Getting to Yes, Roger Fisher, William Ury, Bruce Patton
• Running Usability Studies – Rocket Surgery Made Easy, Steve Krug
david@dfrink.com
