Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Sylvia MacDonald - How the Three Amigos made us more effective - EuroSTAR 2017
Similaire à Sylvia MacDonald - How the Three Amigos made us more effective - EuroSTAR 2017 (20)
Dernier
Dernier (20)
Sylvia MacDonald - How the Three Amigos made us more effective - EuroSTAR 2017
- 2. How The Three Amigos made us an effective team Sylvia MacDonald @SylviaMacD
- 3. Problems There’s been a few... CC image OOPS! Courtesy of leasqueaky on flickr
- 4. Financial report with missing transactions CC image Chrysalis to Butterfly courtesy of Sid Mosdell on flickr Two attempts to fix: • Developer only • No customer input • No tester input
- 5. Financial report project - result Failed – twice! • 1st attempt – no effect • 2nd attempt – abandoned • Customer unhappy • Expensive • One of my favourite projects!
- 6. No conversations = two failures! Lesson learned! • Owner showed me the problem • DBA and I analysed data • Another feature team fixed the bug • Bug fixed within 2 hours
- 7. My top five problems CC image OOPS! Courtesy of leasqueaky on flickr CC image Garbage Dump on the Interstate courtesy of Phil’s 1stPix on flickr
- 8. 1. That’s not what I wanted! With acknowledgements to Businessballs.com and S Hogh
- 9. 2. Trying to solve a problem you don’t understand Not understanding the business problem affects: • The solution • The acceptance criteria • The exploratory testing • The work delivered
- 10. 3. Can you explore something you don’t understand? CC image I Can’t See You… courtesy of Peter on flickr Yes! But understanding helps Yes, but its better if you do!
- 11. 4. Going it alone - work appears in ‘ready to test’
- 12. 5. If only we thought about that before… CC image ‘duh’ courtesy of Charlie Cowins on flickr
- 13. Common theme? Ineffective collaboration! •No conversations •Conversations too late •Not including the right people
- 14. The Three Amigos • What, who, where • Benefits • Challenges • Tips
- 15. What is a Three Amigos session? Collaboration across 3 roles • Business • Developers • Testers Also called Specification workshop
- 16. Why do a Three Amigos? Helps the team answer: • What problem are we trying to solve? (outcomes) • How will we solve it? • How will we test it? • How will we release it? • How do we know its done?
- 17. Brainstorm the scenarios - rules and examples The one where…
- 18. Collaboration isn’t just one meeting – its ongoing!
- 19. Our Three Amigos 1. Backlog grooming 2. Three Amigos meeting 3. Ongoing collaboration
- 20. Is the story ready to be 3 Amigo’d? Backlog grooming session • Once per sprint, 30 mins, 2-4 stories. • Product owner, developer and tester • Led by product owner • Does the story describe the business impact? • Surface unknowns earlier, spikes
- 21. Our Three Amigos process • Every story has a 3 Amigos • Product owner, dev and test • Invite others, eg architects, security • 30 minutes
- 22. Our Three Amigos process - continued • Work though story template • Explore everyone’s suggestions and questions • Update Jira story as we go • Split stories as needed
- 23. Our Three Amigos – location Remote session – UK & Poland • At desks • Via Lync or hangouts • White board huddle • Post it notes!
- 24. Focus on scenarios – rules and examples Rule “Useful message generated when web service end point returns an error”
- 25. Focus on scenarios – rules and examples Rule “Useful message generated when web service end point returns an error” Examples - different messages • 404 config error • 500 error • Time outs • Network error
- 26. Capture anything that affects the story Release strategy: • Toggles • Backwards compatibility • Rollback considerations Other: • Unanswered questions • Decisions • Out of scope work • New stories – split them out
- 27. How are we going to test this? • Testing scope • Rules and examples • Automated checks • Exploratory testing charters • Testing mind map • Mock required? • Any technical difficulty?
- 28. After the Three Amigos session – keep collaborating! • Demos to PO during dev • Dev/Test pairing • Dev & test share test mind map • Follow up all questions • Emerging acceptance criteria
- 29. If the story changes significantly …re 3 Amigo it!
- 30. Benefits gained
- 31. The whole team understands WHAT we are building and WHY
- 32. Identify unknowns earlier Is a spike needed? Do we need to speak to others? • Ops • DBAs • Architects • Professional Services • Feature teams CC image Question 1 courtesy of Virtual EyeSee on flickr
- 33. Reduced surprises – delivery of stories is smoother Better designed stories
- 34. Story splitting improved Smaller focussed stories Reduced scope creep
- 35. Collaboration improved automated test scenarios
- 36. Improved WIP and cycle time Stories pulled by TEAM rather than pushed by an individual CC image Highland Regiments Tug-of-War courtesy of Jamie McCaffrey on flickr
- 37. Less escaped bugs in test staging environment CC image ‘2 Pet Crickets having fun, dancing and doing handstands’ courtesy of I a walsh on flickr
- 38. Dev and test share knowledge and skills Developers became better testers Testers improved technical skills Mutual respect for each other CC image group hug courtesy of Mel Aclaro on flickr
- 39. Main challenges CC image Obstacle Race – Dornoch Highhland Gathering 2007 courtesy of John Haslam on flickr
- 40. Reluctance – willing to try but not sure of the benefit CC image ‘Is there any food left for me?’ courtesy of Beverley Goodwin on flickr
- 41. Calendar clashes - people not available at the same time
- 42. Given/When/Then syntax during 3 Amigos Give / When / Then Given the call accesses the web service When the web service returns a 404 error Then a service not found config error message is written to the logs
- 43. Given/When/Then syntax de-railed 3 Amigos Rule & examples “Useful message logged when end point returns an error” 404 = configuration msg 1 Time outs = configuration msg 2 500 = error msg 1 Network error = error msg 2 Give / When / Then Given the call accesses the web service When the web service returns a 404 error Then a service not found config error message is written to the logs
- 44. It’s too small for a 3 Amigos CC image “Here’s looking at you’ courtesy of vagawi on flickr
- 45. Top 10 tips 1. Three Amigos is a collaboration mind set 2. People doing the work attend the sessions 3. Everyone participates – it’s not a presentation 4. Be prepared - come with ideas and questions 5. Ensure everyone is happy before moving on 6. Use example mapping and good story splits 7. Build a shared testing artefact 8. Acceptance criteria in plain language – automate after 9. Time box session to 30 – 60 minutes max 10. Book daily sessions in the calendar to build habits
- 46. What’s the complication, it’s only conversation… Credits: The Feeling – Love it when you call. How can you start? 1. Run an experiment – have a 3 Amigos session! 2. Start talking to your colleagues more 3. Ask questions as early as possible 4. If it looks like a solution, ask what the business impact is. 5. Offer to pair with your dev or tester. 6. Join relevant meetings.
- 47. Some resources Books 1. Fifty Quick Ideas to Improve Your User Stories - Chapter: Involve all roles in the discussion 2. BDD in Action by John Ferguson Smart 3. Specification by Example by Gojko Adzic 4. The BDD Books – Discovery Explore behaviour using examples by Gaspar Nagy & Seb Rose Articles and tools https://cucumber.io/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool https://cucumber.io/blog/2015/12/08/example-mapping-introduction http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/ http://itsadeliverything.com/three-amigos-meeting-agree-the-tests-before-development-starts https://gojko.net/2008/11/12/specification-workshops-an-agile-way-to-get-better-requirements/ http://www.teamuplabs.com/
- 48. Questions? Sylvia MacDonald Engineering Manager at NewVoiceMedia @SylviaMacd Meetup - Reading Tester Gathering
Notes de l'éditeur
- In my career I’ve worked with some really talented people – developers, testers, product owners and business analysts. But we experienced some problems over and over again. Some teams were waterfall but most were working in an Agile way with sprint planning, design sessions of some kind and daily stand ups. The main problem I saw was work we thought was finished coming back with bugs or not being quite what the customer was expecting. Then about 3 years ago I attended a BDD workshop run by Matt Wynne in London. The first day was very interesting and really stood out for me. It was about the 3 Amigos and how effective collaboration can improve our story development. In my experience, the Three Amigos approach did make us a more effective team. By that I mean we delivered value quicker and with little or no failure demand.
- Before I tell you about the Three Amigos, I’m going to go over the most common problems I’ve seen in the teams I’ve worked with. The Three Amigos way of working helped my team get over these problems.
- I was a contract developer in a large financial organisation in London. We produced a transaction report for our customers but it was missing some stock exchange transactions – customers unhappy. Two separate attempts to fix by different developers. Picture – attribution reqd - https://static.pexels.com/photos/53621/calculator-calculation-insurance-finance-53621.jpeg
- First attempt – investigated, coded and tested by the developer. Made no difference. 2nd attempt – investigated and solution devised by developer. They realised it wouldn’t work but didn’t know what to do next. Quite rightly stopped the project. Pixabay picture, no attribution rqd - https://pixabay.com/en/mistake-error-question-mark-fail-1966448/
- Favourite project –valuable lesson - effective collaboration is key to delivering value Its about people with different expertise talking to each other early and often. Eg talked to customer, DBA, other feature team – bug fixed in 2 hrs
- That financial report example we’ve just talked about shows the 5 common problems I’ve seen happen in lots of teams. I’ve found that the Three Amigos helped us avoid all of those problems.
- Customer/PO describes what they want. Team develops it. Team demo’s it to PO at the end. Customer expectations are not quite met – either due to misunderstandings or because it is what the customer asked for but its not what the customer actually needed.
- Not fully understanding the WHY leads to not fully exploring the possible solutions and often building the wrong thing. You may have developed it the right way with great code and techniques, but if it doesn’t solve the business problem, you haven’t delivered value.
- If testers don’t know the context or WHY we are doing the story, they test against the spec instead of seeing whether our solution gives value to our customers. Understanding the user’s real world and the jobs they are trying to do means you can test with that focus in mind. This situation often happens when testers are: - Not in kick offs Not asking questions Too shy to say they don’t understand the solution or the architecture
- I’ve seen this where - Coding starts before the rest of the team had any input, eg ‘weekend work’ or the developer was ready so picked up a story and just got going on it Testers didn’t know anything about the story they were testing – its context, solution, architecture etc I’ve seen this cause customer impacting incidents resulting in urgent work need to create and release a fix, often interrupting people in other teams.
- This is about failure demand. Where we have to re-visit development because not all aspects were considered before starting coding. The PO, developer and tester may have talked about the work, but not very effectively. We end up with bugs to fix or ‘enhancements’ to develop.
- So that’s a quick overview of some common problems I’ve seen in software delivery. Problems I’ve seen solved by my team doing Three Amigo’s Now lets look at the Three Amigos: - who they are, what they do, the benefits we gained that made us more effective team, and the challenges we had to overcome in the process. Plus some tips on getting started with Three Amigos if you aren’t already doing them.
- A three amigos session is about collaboration across three roles, three voices - the business represented by the PO / BA / Customer, developers who understand the code and the architecture, the technical side the testers with their curiosity and their exploratory mindsets. You may have heard them called story kick offs or specification workshops, especially if you’ve read Gojko’s book - Specification By Example
- Why would you do a Three Amigos? So that the team has a common understanding of WHAT we are building and WHY we are building it. What’s the business impact we are trying to make? What real world customer problem are we solving? What outcome is wanted? How will we solve the problem? How will we test it, release it, and support it? How do we know we’ve been successful? All of these are things that the team can answer during a Three Amigos. Having a good understanding of all this means the team has a much better chance of delivering value.
- During a three amigos, we work out the acceptance criteria. We do that by brainstorming the various scenarios, working out the rules for the story, and the examples that show those rules in action. Because the PO is involved, you can quickly get clarification on any business context or questions. The exploratory testing mindset here is invaluable. Testers will often think of all sorts of situations that we need to cover – those ‘what happens if….’ situations
- Three amigos isn’t just one meeting. It’s a collaboration mindset. Its about those three voice continuing to talk to each other throughout the development process.
- As you can see, its not rocket science. Its about people with different expertise talking to each other early and often to understand WHY we are doing the work, HOW we are doing the work and HOW we know we’ve added some value. So here’s how the Three Amigos fitted into our team processes. 2 week sprints with planning, daily stand ups and retros A short backlog grooming session which I’ll explain in a minute. We do a Three Amigos for every story we work on.
- Backlog grooming session was about making sure the next few stories we about to work on were in a fit state for a Three Amigos We’d make sure the story described the business impact - the problem to solve - the context, the WHY. (not a big long analysis, just the usual placeholder for a conversation) Sometimes we’d quickly realise we didn’t know enough to progress the story any further – a spike was needed or we had questions that had to be answered first. Advantages – we came to the Three Amigos better prepared and we surfaced unknowns earlier. 30 mins = 2-4 stories
- This is our Kanban board. First column is the Three Amigos column. Every story has a Three Amigos before work starts on it. The PO, devs and testers came to the Three Amigos. Depending on the story, we’d invite others to come too – architects, security or performance specialists. 30 mins
- Everyone has a voice - don’t let dominant personalities take over. Everyone is an active participant. Knowing each other well helps – forming, norming, storming, performing Understand each other’s body language, facial expressions
- Many ways to Three Amigos - see slide Omnichannel team split between UK and Poland. All Three Amigos were remote via video conferencing and online collaboration tools. Two of the devs developed an Example Mapping tool to help them with their rules and examples.
- Flesh out the acceptance criteria with rules and examples. Example mapping techniques. Rule must be clear – eg a useful message for ops/support when end point returns an error Testers asked questions re different error types => different messages?
- Flesh out the acceptance criteria with rules and examples. Example mapping techniques. Rule must be clear – eg a useful message for ops/support when end point returns an error Testers asked questions re different error types => different messages?
- Toggles for two reasons Trunk based development => protect the customer from work in progress Paid for features – only available to customers on certain license levels
- A powerful question – I’ve seen this change the design of the solution.
- Remember the Three Amigos isn’t just one meeting – it’s a collaboration mindset. Pic: https://static.pexels.com/photos/38940/pexels-photo-38940.jpeg
- Things may change as Questions get answered Requirements change - business reasons change
- So that was an overview of how we incorporated the Three Amigos into our team’s processes. Now I want to go over some of the main benefits we experienced that helped my team work more effectively.
- I know I’ve said this a few times already but it really was one of the most important effects of the doing Three Amigos. Because we understood the WHY, we built the right thing first time more often. That made the team happy, productive and improved our work flow
- For example - Provision servers, - Architectural and database considerations, - User input and feedback on our ideas, eg PS, Customer Support, Ops., customers (where possible)
- We had less unknowns cropping up during story development. Eg- error messages – During Three Amigos, decided to check the wording of our intended error messages with Support and Ops. They didn’t find them useful. We changed them. Would have been a delay and rework if we hadn’t asked them early on. Pic: pixabay - https://pixabay.com/en/dinosaur-mirror-wing-mirror-behind-1564323/
- Naturally evolved out of the discussions we had in our Three Amigos Discussed what was in and out of scope Especially the brainstorming the scenarios, rules and examples. Sometimes a scenario would become a new story. Pic: https://hd.unsplash.com/photo-1455884981818-54cb785db6fc
- Having the PO, Dev and Tester working out good rules and examples for our acceptance criteria’s together resulted in us having more useful automated tests. The rules and examples became our automated tests. This Reduced our level of failure demand (bugs and rework) due to misunderstandings about what the problem we were trying to solve was, and how the system was supposed to work. Experiment with example mapping techniques.
- Because every story had a three amigos resulting in a good understanding of the work to be done, we focused on finishing that story, before moving on to the next. Our WIP limits became more realistic and cycle time decreased. This ties in with Kanban and its emphasis on flow of work, and systems thinking Stop starting and start finishing
- MV – 30-50 bugs on a story. At NVM, team was a bit shocked when we got a bug – ‘how did that happen’ in retro or a mini 5 Whys. Often due to 3 amigo skipped, or not having the right people involved. https://www.flickr.com/photos/ivanwalsh/4133409822/
- After working closely with developers, the testers technical skills improved. Started doing some stories – writing SQL, Javascript etc Developers would code review and help with refactoring which further improved the tester’s skills. Developers exploratory testing skills improved too as they saw how we testers thought. Sharing out testing mind maps with them encouraged them to exploratory test as well. After Alex, the tester, found a bug, the Developer said – “I wanted to find that bug. I was trying to think like Alex!” How powerful is that – the whole team thinking like exploratory testers! On another team, after working with the exploratory tester, the developers said they now understand why exploratory testing is valuable. Its helped them do better work.
- Wasn’t all plain sailing. We did have some problems.
- What – another meeting! Waste of time – just want to crack on and code, do some real work. Team has a culture of experimenting so were willing to give it a go. Pic: https://www.flickr.com/photos/bevgoodwin/10551419673/
- Initially the main problem we had was people not being available to do a Three Amigos. Normally it was the tester not available – at NVM testers do other jobs to, eg improving our release process. We hadn’t formed the habit of doing three amigos yet. Solution – put two 30 min slots a day in everyone’s calendar so we were always available twice a day. In stand up we’d work out if we needed a Three Amigos today Once the habit of always doing a Three Amigo’s was formed, we didn’t need the calendar invites anymore.
- We automate our acceptance criteria using Specflow. We tried to write the scenarios in Gherkin during the Three Amigos. We ended up focusing on getting the Gherkin syntax right instead of thinking about all the possible scenarios. This lead to increased failure demand - more bugs and rework because we had missed scenarios an acceptance criteria. Also meant our Three Amigos sessions took a long time and people got frustrated, bored, distracted and a bit grumpy.
- Instead, focus on getting the scenarios fleshed out with rules and examples in normal language. We’ve used bullet points, simple tables – anything that is clear and works. We did the Gherkin G/W/T later when automating.
- 5-10 min chat is still a 3 amigo Story of 10 minute chat that changed design of a bug fix – popped out of all day training, developer grabbed me Pic: https://www.flickr.com/photos/vagawi/1391672150/in/photostream/
- If you aren’t doing 3 Amigos at the moment, how can you get started? Big bang Baby steps