Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Overcoming Resistance - How to Engage Developers in Agile Adoption

644 views

Published on

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

Published in: Technology

Overcoming Resistance - How to Engage Developers in Agile Adoption

  1. 1. Overcoming Resistance - How to Engage Developers in Agile Adoption David Frink Agile 2017 Orlando, FL
  2. 2. David Frink Agile Coach, Release Train Engineer, Development Manager, Developer Ipreo, Teradata, SciQuest PSM, ICP-ACC, ICP-ATF, ICP, SAFe 4 RTE david@dfrink.com
  3. 3. What do you hope to get out of this presentation?
  4. 4. Can you “do” agile or do you have to “be” agile?
  5. 5. Can you “do” agile or do you have to “be” agile?
  6. 6. Agenda • Two types of engagement • Where motivation comes from • Non-engagement and the developer’s mind • Ways to encourage engagement as attitude • Ways to encourage engagement as behavior • Conclusion
  7. 7. Technical Work Usability Agile Practices Documentation Demos Engagement as Behavior Testing & Quality Know the User & Business
  8. 8. Technical Work Usability Agile Practices Documentation Demos Testing & Quality Know the User & Business Engagement as Behavior
  9. 9. Technical Work Usability Agile Practices Documentation Demos Testing & Quality Know the User & Business Engagement as Behavior
  10. 10. FrontEndBackEnd FrontEndBackEnd Testing UX Doc
  11. 11. Engagement as Attitude •To see this in action, look outside of work •Hobbies •Volunteer work •You bring the energy and motivation •How do we help this arise within our teams?
  12. 12. Technical Work Usability Agile Practices Documentation Demos Engagement as Attitude Testing & Quality Know the User & Business
  13. 13. Two Types of Engagement • Behaviors (participating, swarming, helping to test, etc.) • Attitude/intrinsic motivation (drives behavior) • Gallup Engagement Survey • Where does motivation for change come from?
  14. 14. Elephant & Rider Rider – Logic, analysis, planning, self-control, long-term thinking Elephant – Emotion, motivation, passion, fear, loyalty, short-term thinking
  15. 15. 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 Superhero complex (only I can save the day!) Don’t care about the users
  16. 16. You’ve got an elephant problem
  17. 17. 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 • Waterfall vs scrum • Value structure and order, high need for control and predictability • Problem solvers; like solving puzzles
  18. 18. How to Engage
  19. 19. Technical Work Usability Agile Practices Documentation Demos Engagement as Attitude Testing & Quality Know the User & Business
  20. 20. 6 Degrees of Knowing Your User Dev/Test PO PM AM Admin Actual User
  21. 21. Engagement as Attitude •Customer On-site Visits •Usability Studies •Threaten to Put It Into Production •Give Problems, Not Solutions
  22. 22. Customer On-site Visits •5 minutes with a real user is worth a hundred pages of functional spec •Meeting real people engages the elephant •Implementation ride-alongs •Will it work here? •vs. “How might we?” •A way to measure
  23. 23. Usability Studies • Next best thing to meeting a user • A person, in front of your system with simple instructions, thinking out loud, with the team observing • Connects to the elephant, gives you insights that won’t survive the “6 degrees” • How your team will object… • Inexpensive and effective • How might we…
  24. 24. Threaten to Put It Into Production • Show screenshots and threaten to put it into production tomorrow • Will engage the customer’s elephant b/c of the threat – get good feedback quickly • First 4 calls, have the team there • Resist the urge to summarize to “save the team time”
  25. 25. Give Problems, Not Solutions • Do your stories have too much detail? • Am I solving my own problem or just implementing your solution? • “We don’t want them to be bricklayers”
  26. 26. Engagement as Behavior • Airplane Mode • Fist of 5 • Retrospectives • Clarity of Purpose • Find the Bright Spots and Give Feedback
  27. 27. Treat them like we treat our users… what they ask for isn’t what they really need
  28. 28. “Agile has too many meetings” • It’s not about the meetings • It’s about uninterrupted work time (flow) • To fix this complaint, protect your team’s focus • Airplane mode • Without adequate focus, they will be frustrated • Working agreements, cluster meetings, etc.
  29. 29. Fist of 5 • Generates dialog • Uncovers resistance • Creates buy-in
  30. 30. Retrospectives • Look here first • Allows for self-healing teams • Try something you think will fail • Don’t be afraid to have a “meta-retrospective"
  31. 31. Clarity of Purpose • If you ask, “What is the purpose of this refinement 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
  32. 32. Find the Bright Spots and Give Feedback • Focus on what works and reinforce it • Assume they can’t tell which behaviors are beneficial • Assume positive intent • Assume nobody else is giving them positive feedback • Situation, Behavior, Impact (SBI) • 5-1 ratio
  33. 33. Conclusion • Know your user • Know your user (by their first name) • Onsite, Usability Study, Threaten to put into production • Give problems, not solutions • Motivate the elephant…but don’t scare it • Engagement behavior • Airplane mode • Fist of 5 & effective retrospectives • Clarity of purpose • Assume positive intent, find bright spots & give feedback
  34. 34. Questions & Thanks! For additional resources: www.dfrink.com/resistance david@dfrink.com

×