Behavioral hypothesis of team behavior
0 likes90 views
The document discusses a behavioral hypothesis for team formation based on three critical conditions: 1) a shared, voluntary goal that is embraced by all team members; 2) a goal that is not achievable by any individual alone and requires teamwork; and 3) an appropriate level of challenge that is not too easy or too difficult. It proposes that if these conditions exist, team formation will naturally begin through a process similar to Tuckman's stages of forming, storming, norming, and performing. Several practices are described that can help foster an environment where these three critical conditions exist, such as collaborative user story writing, team-written acceptance criteria, and emphasizing shared rather than individual goals.
Behavioral hypothesis of team behavior
- 1. 1 Agile Training and Coaching - © 2018 Petri Heiramo, Agilecraft Ltd, Finland Behavioral Hypothesis of Team Formation Scrum Gathering London, 2018 Petri Heiramo, CST, Agilecraft Ltd
- 2. Classic Explanation of Behavior Images from Wikipedia
- 3. Classic Explanation of Behavior vs
- 4. Kurt Lewin Principles of Topological Psychology, 1936 B = ƒ(P, E) Image from Wikipedia B = Behavior, P = Personality, E = Environment
- 6. Please stand up, if… 1. You regularly eat candy and chocolate before lunch 2. You believe it’s healthy and a good idea to eat candy and chocolate before lunch 3. You have taken candies or chocolate from the tables and chairs
- 7. I assume you know the following already…
- 8. Workgroup Team “Sum of its parts” ”We need synergies” Individual goals Shared goals Individual responsibility Shared responsibility Centralized and assigned leadership Emergent leadership (although formal leader exists) Individual behaviors Shared behaviors I can “win” even if you “lose” Everyone “wins” or “loses” together
- 9. 9 Agile Training and Coaching - © 2018 Petri Heiramo, Agilecraft Ltd, Finland Communication Looks Like This Workgroup Team
- 10. Teams >Σ" Workgroups =Σ" Valuecreationability Time Low risk Cognitively easy Low emotional investment High risk Cognitively challenging High emotional investment
- 11. Tuckman Model Forming – come together and accept the goal, avoidance of conflict Storming – disagreements voiced and argued, no agreement Norming – behavioral alignment and continuous improvement Performing – very effective operation and exceptional value delivery Forming Storm ing Norming Perform ing
- 12. Ok, then…
- 13. If( TeamFormation == Behavior, LewinsLaw == True ) { if (X, Y, Z,…) { Team.Form.Begin } }
- 14. Google: Project Aristotle Psychological safety Can we take risks on this team without feeling insecure or embarrassed? Dependability Can we count on each other to do high quality work on time? Structure & clarity Are goals, roles, and execution plans on our team clear? Meaning of work Are we working on something that is personally important for each of us? Impact of work Do we fundamentally believe that the work we’re doing matters?
- 15. You First Discuss with your neighbor, what conditions do you perceive as critical for team formation to begin?
- 16. There are 3 critical qualities that initiate or prevent team formation. I deeply suspect that…
- 17. Shared Voluntary Goal Everyone knows the Vision • What, why, who, when, how, … Can be external or internal goal Accepted personally by everyone • Worth striving for
- 18. Goal Not Achievable Alone If achievable alone, why spend the effort to team up? Goal must integrate the work of all team members Focus on end result, not on components or activities
- 19. Appropriate Challenge Too easy à no need for teamwork Too hard à people give up Frustration Boredom Challenge Skill Flow Teams also enter “flow”, though it looks a little different
- 20. Flow What Often Happens: A Better Approach: Flow Frustration Boredom Challenge Skill Frustration Boredom Challenge Skill Apathy
- 22. Speed, Ease Co-location Development framework Variety Personalities Culture Coaching Knowledge Tools
- 23. Take a moment, and… • Think of the project or product team you are part of now (or working with) • Write down (2 min) • What is your team’s goal? Is it voluntarily embraced by everyone? • Do team members need each other to reach that goal? • Is the goal appropriately challenging? • If you feel that some condition is not present, note that down, too • Discuss your notes with your neighbour (4 min) • See if you can help each other improve/clarify the conditions
- 24. As a coach… 1. Ensure that the three conditions are true 2. Use catalysts to speed up and ease the natural process 3. Profit
- 25. We can take this hypothesis further.
- 26. An example of a possible state map for a character in a strategy game. http://flylib.com/books/en/4.70.1.87/1/
- 27. Forming Storming Norming Performinga, b, c, … h, i, j, … o, p, r, … l, m, n, … u, v, w, … å, ä, ö, … x, y, z, … s, t, u, … e, f, g, …
- 28. Conditions for AdvancementForming storming • Safety • Courage And the 3 Conditions, of course
- 29. Conditions for Advancementstorming norming • Mechanism to decide together • Commitment to decisions • Clear boundaries • Trust and respect
- 30. Conditions for Advancementnorming performing • Ambition / Relentless Improvement • Discipline • Personal competence • Embracing variety • Stable team
- 31. Conditions for MaintenanceperForming • Continued big challenges • Often driven by team itself • Appropriate change • Scrum, Inc.: 20% change • Keep wolves at bay
- 32. In the behavioral hypothesis, we have: 3 Critical Conditions Catalysts Conditions of Advancement
- 33. One Last Thing…
- 34. Intrinsic motivation is driven by: Autonomy Mastery Purpose (assuming that respect is taken care of)
- 35. Let’s Compare Motivation Autonomy Mastery Purpose Team Formation Shared Voluntary Goal No-one Can Win Alone Sufficient Challenge
- 36. Summary If the hypothesis is correct, trying to make teams jell is useless. Create right conditions, and people will start to self-form.
- 37. AVOID … trying to convince people … using trickery or sleight-of- mind (e.g. bonuses, dishonesty, flattery, made-up deadlines) … applying pressure EMBRACE … a meaningful shared goal … techniques that bring people together … open-ended challenges … coaching through the stages
- 38. I invite you to test the hypothesis, and send your feedback to Petri Heiramo Agile Trainer & Coach, CST Agilecraft Oy petri.heiramo@agilecraft.fi Kiitos!
- 39. Practices to help foster an environment with the 3 Critical Criteria Additional Content!
- 40. Shared Vision Workshop The PO and Development Team collaboratively clarify that both have the same Vision in their minds. Remember to involve all Team members! Make Team do it – PO consults. Focus on next release only Key things to remember: • Only allow 3-4 critical features / elements • Fun is better than not fun • Visual trumps text • Iterate a few times
- 41. Internal Goal Sometimes the external goal is not sufficient for team formation Ø E.g. not challenging enough, or not open-ended enough The team can self-select a twist that adds challenge Ø E.g. faster delivery, using new or better techniques, higher quality, as a team, one hand behind back,… Key things to remember: • Safe to fail! Don’t tell others J • Ok, maybe the PO should know
- 42. Increase Challenge over Time Don’t give the Team the full challenge at first Start with a simpler, smaller part, then expand Ways to increase challenge Ø Add new features over time Ø Make challenges more open-ended Ø Experiment with new tech, etc. Ø Learn new techniques Ø Increase quality Key things to remember: • Keep the big picture in mind • Use proper Agile development techniques • Requires PO’s understanding and engagement
- 43. Increase Challenge over Time Don’t give the Team the full challenge at first Start with a simpler, smaller part, then expand Ways to increase challenge Ø Add new features over time Ø Make challenges more open-ended Ø Experiment with new tech, etc. Ø Learn new techniques Ø Increase quality Key things to remember: • Keep the big picture in mind • Use proper Agile development techniques • Requires PO’s understanding and engagement
- 44. Collaborative User Story Writing User stories are reminders of conversations had and to be had PO and Team write the stories together Focus on bigger picture over too much detail Ø Cover all users and features with at least one story each Recommendations: • Don’t split up the group to subgroups • Use physical tools, like index cards • Print out any materials that contain references or prior work • Reserve about 60-90 minutes • Aim to 30-40 stories
- 45. Team Writes Acceptance Criteria Request that the Team writes the acceptance criteria for the stories Forces Team to study the features together Confirms their understanding to PO Recommendations: • Keep PO close by • Use iteratively in refinement meetings • PO needs to approve the criteria and should clarify any criteria the Team “did not get right”
- 46. Story-Level Design For each user story going into a Sprint, create a ”one-page” shared design Ø User flow and design Ø Technical design Ø Database changes Ø Testing Describes what the system will look like after the story is done Recommendations: • Should only take 15 minutes for most stories • Use flipcharts or whiteboards • Whole team participates (or at least all disciplines) • Can be done either in refinement or Sprint Planning • Extract tasks from this design
- 47. No Individual Goals Avoid anything that would create individual goals over shared goals For example: Ø No names on stories Ø Don’t assign tasks in Sprint Planning Ø Only allow names in Daily Scrum Use real user stories for Product Backlog items Recommendations: • If you have to put an assignment on a story, use “Team” • Face magnets can help (also enforces WIP limits) • Tasks should be an average ½ days, so that people can’t disappear into a “cave” for long
- 48. Different Daily Questions 1) Of the things I did yesterday, what do others need to know? 2) Of the things I plan to do today, where do I need help or coordination with others? 3) What is blocking or slowing us down?
- 49. Fourth Daily Questions “Are we still able to deliver to our commitment?” The Team answers this together at the end of the Daily Scrum Use for example thumb voting
- 50. Collaborative ATDD All team members collaborate to define and implement automated acceptance tests Define what to test together Pair programmers and testers to automate them Recommendations: • Add these tasks to task board • Teach programmers to create scripts, teach testers to modify & copy/paste automations • Automate the tests before coding
- 51. Pair Work Pair all production code (programmers) Pair all acceptance tests (programmers and testers) Pair exploratory testing (testers with anyone else) Pair design (designers with anyone else) Pair learning (everybody) Recommendations: • Driver only “types” • Navigator thinks • Rotate often • If one person is much more senior, they should mostly navigate • Plan for pairing in Daily Scrum
- 52. Mobbing More than two people doing something together Mob programming, mob testing, etc. Recommendations: • Driver only “types” • Multiple navigator think together • Rotate very often • If you mob as a full team, you no longer need Daily Scrum and many other things Check the Mob Programming video from https://www.youtube.com/watch?v=dVqUcNKVbYg