Power of the Swarm - Agile Serbia Conference 2017
•
4 likes•746 views
This document discusses practices for solving complex problems in an agile team environment through swarming or collective intelligence. It defines complex problems as those with no single solution due to competing factors, and explains that the best solutions emerge through interactions between people with diverse viewpoints. Effective swarming practices discussed include having the product owner and team collaboratively develop a shared vision and user stories, with the full team designing and testing stories together. The document recommends practices like mob programming and pairing to encourage collaboration over individual work and ensure all team members contribute to problem solving.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Power of the Swarm - Agile Serbia Conference 2017
Similar to Power of the Swarm - Agile Serbia Conference 2017 (20)
Recently uploaded
Recently uploaded (20)
Power of the Swarm - Agile Serbia Conference 2017
- 1. 1 Agile Training and Coaching - © 2017 Petri Heiramo, Agilecraft Ltd, Finland Power of the Swarm! Tuning Your Teamwork Petri Heiramo, CST, Agilecraft Ltd
- 2. 1) What is a “complex problem”? 2) Solving complex problems 3) What is “swarming”? 4) Effective practices for swarming that also create teamwork
- 4. Simple problem – obvious solutions Complicated problem – difficult solutions, require time and expertise, can usually be broken down to smaller problems Chaotic problem – no solution J
- 5. Multiple competing factors that need to be considered Usability Maintainability Architecture Performance Testability Compatibility Productivity QualityDependencies LimitedTime Learning
- 6. Can’t be broken to subproblems Different aspects are connected dynamically and non-linearly
- 7. No single optimal solution
- 8. In hindsight, the best solutions seem obvious, but were really hard to come up with
- 9. Many people would’ve tried to solve this problem in more complicated ways
- 11. Solution is emergent • Interactions between people • Combining old ideas in novel ways • Refinement through iterations
- 12. Different viewpoints are needed Yet it’s very hard for anyone to hold multiple viewpoints simultaneously
- 13. This is us and our thinking Due to our personality, experiences, etc. we have “blind spots”
- 14. The more we are alike, the more our blind spots overlap
- 16. In Teams, our shared focus helps us cover each others’ blind spots
- 17. Yet even great teams may still have shared blind spots
- 18. So if this is our problem … and that solving it requires ”connecting these dots”…
- 19. … then this person will have trouble solving it
- 20. And so do these two, even together
- 21. This team gets close, but still not varied enough
- 22. Age Gender Education Profession Skills Knowledge Work History Role Nationality Hobbies EthnicityCulture Language Personality Likes and Dislikes Wealth Experience
- 23. Developing SW is a Complex Problem • Continually changing customer requirements • Need to combine different skills within the team • Desire for high technical quality • Deadlines constrain available time • The team should continually improve their work • Need to co-operate despite our differences • Etc.
- 26. One brain thinks at fixed speed
- 27. It cannot think faster
- 28. It also thinks at certain quality
- 29. To really think faster and better, we need to “parallelize” brains
- 30. And make them think about the same thing at the same time Often easier said than done
- 31. swarming /swɔːmɪŋ/ verb More than one brain thinking of the same problem together at the same time
- 32. Effective practices for Swarming (that also create teamwork) 4
- 33. 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
- 34. 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
- 35. 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”
- 36. Story-Level Design For each user story going into a Sprint, create a ”one-page” shared design Ø User flow and design Ø Acceptance testing Ø Technical design Ø 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
- 37. 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
- 38. 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?
- 39. 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
- 40. Collaborative Refinement Whole Team works to identify open items for clarification Place open items to task board Estimate together (e.g. Planning Poker) Ø Only a single number that includes everyone’s effort Recommendations: • Do not assign open items to anyone • People pull those tasks in Daily Scrum • Reserve 5-10% of Team’s time for these tasks in every Sprint
- 41. 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
- 42. 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
- 43. 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
- 45. Thanks! Petri Heiramo Agile Trainer & Coach, CST Agilecraft Oy petri.heiramo@agilecraft.fi