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.

Agile prague 2017 - Real Teams - Petri Heiramo

0 views

Published on

A slightly different, behavioural take on team formation - foundations, support, and practical tools, to support the growth of the team.

Published in: Leadership & Management
  • Be the first to comment

  • Be the first to like this

Agile prague 2017 - Real Teams - Petri Heiramo

  1. 1. 1 Agile Training and Coaching - © 2017 Petri Heiramo, Agilecraft Ltd, Finland Real Teams Easier Said And Done Petri Heiramo, CST, Agilecraft Ltd
  2. 2. 2 Agile Training and Coaching - © 2017 Petri Heiramo, Agilecraft Ltd, Finland Foundation Journey Practices Journey
  3. 3. 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
  4. 4. 5 Agile Training and Coaching - © 2017 Petri Heiramo, Agilecraft Ltd, Finland Communication Looks Like This Workgroup Team
  5. 5. Teams >Σ𝑝 Workgroups =Σ𝑝 Valuecreationability Time Low risk Cognitively easy Low emotional investment High risk Cognitively challenging High emotional investment
  6. 6. 3 Conditions
  7. 7. B = f(P, E) B = Behavior, P = People, E = Environment Lewin's equation, Kurt Lewin,1936:
  8. 8. Forming into a team is a natural human response to certain conditions in the environment.
  9. 9. if (X, Y, Z) then team.form()
  10. 10. X) Shared Voluntary Goal Everyone knows the Vision • What, why, who, when, how, … Can be external or internal goal Must be accepted personally by everyone • Worth striving for
  11. 11. Y) 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
  12. 12. Z) Appropriate Challenge Too easy à no need for teamwork Too hard à people give up Teams also enter “flow”, though it looks a little different Frustration Boredom Challenge Skill
  13. 13. Catalysts
  14. 14. Speed, Ease Coaching
  15. 15. Conditionsof Advancement
  16. 16. Imagine a state machine
  17. 17. Once certain conditions are achieved, the machine automatically moves to a new state
  18. 18. An example of a possible state map for a character in a strategy game. http://flylib.com/books/en/4.70.1.87/1/
  19. 19. 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, …
  20. 20. 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
  21. 21. Conditions for AdvancementForming storming • Safety • Courage
  22. 22. Conditions for Advancementstorming norming • Ability to decide together • Commitment to decisions • Clear boundaries • Trust and respect • Acceptance of differences
  23. 23. Conditions for Advancementnorming performing • Relentless improvement • Discipline • Personal competence • Embracing variety of opinions • Sufficiently stable team
  24. 24. Conditions for MaintenanceperForming • Continued big challenges • Appropriate change • Scrum, Inc.: 20% change • Keep wolves at bay
  25. 25. Practices Effective Team
  26. 26. Shared Release Vision 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
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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”
  31. 31. 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
  32. 32. 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
  33. 33. 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?
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. https://www.youtube.com/watch?v=dVqUcNKVbYg
  39. 39. Conditionsof Advancement 3 Conditions Practices Catalysts Effective Team
  40. 40. Summary Trying to make teams jell is useless. Create right conditions, and they will start to self-form.
  41. 41. Summary DON’T … try to convince people … try trickery or sleight-of-mind (e.g. bonuses, dishonesty) … apply pressure DO … help form a clear shared goal … use techniques that bring people together … provide open-ended challenges … coach through the stages
  42. 42. Thanks! Petri Heiramo Agile Trainer & Coach, CST Agilecraft Oy petri.heiramo@agilecraft.fi

×