Don't be a zombie reading your stories - Learn the exciting parts of analysis - YOW! West - 03_05_2016
•Download as PPTX, PDF•
3 likes•881 views
For some teams, having a Business Analyst would be a luxury. For others, they are no longer necessary. Whatever your situation, analysis and critical thinking is still essential in software development. Even if you don’t have a Business Analyst! During this talk, you will learn how to become a Business Analyst while still being a developer, tester, or product manager. I will introduce some of the secrets that great Business Analysts use to get people collaborating, discussing the problem, and agreeing on a solution. Learn how to run a design studio, 3 amigos session, or a story kickoff. Don’t just be a zombie reading your next ticket. Let’s think about the problem and how we’ll solve it together!
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Don't be a zombie reading your stories - Learn the exciting parts of analysis - YOW! West - 03_05_2016
Similar to Don't be a zombie reading your stories - Learn the exciting parts of analysis - YOW! West - 03_05_2016 (20)
More from Ryan McKergow
More from Ryan McKergow (11)
Recently uploaded
Recently uploaded (20)
Don't be a zombie reading your stories - Learn the exciting parts of analysis - YOW! West - 03_05_2016
- 1. Don’t be a zombie reading your stories Learn the exciting parts of analysis Ryan McKergow ryanmckergow rmckergow
- 2. think sharp rmckergow What will we cover? 1.What does your team look like? 2.Analysis is essential 3.Exciting techniques to take home
- 3. think sharp 1. What does your team look like? Where’s the Business Analyst?
- 4. think sharp rmckergow Australian corporate agile team Business Analyst/s Developer/s Tester/s Architect Product Owner Project Managers
- 5. think sharp rmckergow Australian digital agile team Business Analyst/s (optional) Developer/s Tester/s Product Owner Delivery Lead
- 6. think sharp rmckergow Scrum teams (as per the Scrum Guide) Development Team Product Owner Scrum Master
- 7. think sharp rmckergow Scaled Agile Framework (SAFe) teams Agile Team Product Owner Scrum Master
- 8. think sharp rmckergow Start ups & digital agencies Developers Project Manager or Business person
- 9. think sharp rmckergow What do we do about analysis then?
- 10. think sharp 2. Analysis is essential
- 11. think sharp rmckergow Analysis?! That’s not my job… Can you just tighten this bolt up? Sorry mate. I’m a bolt loosener. You’re going to need a bolt tightener.
- 12. think sharp rmckergow T-shaped individuals Breadth Depth
- 13. think sharp rmckergow Poor analysis creates costly defects Refer to this article featuring @scottwambler: http://bit.ly/costofchange Cost Length of feedback cycle Analysis defects found via traditional acceptance testing
- 14. think sharp rmckergow Collaborative analysis reduces cost of defects Refer to this article featuring @scottwambler: http://bit.ly/costofchange Cost Length of feedback cycle Analysis defects found via active stakeholder engagement / participation Analysis defects found via collaborative workshops
- 15. think sharp rmckergow Poll: Can you relate? development team
- 16. think sharp rmckergow Reading stories ≠ shared understanding Communicationeffectiveness Richness of communication Reading a document / stories Refer to this article featuring @TotherAlistair: http://bit.ly/agilecomms
- 17. think sharp rmckergow Talking to people = shared understanding Communicationeffectiveness Richness of communication Face to face conversation Refer to this article featuring @TotherAlistair: http://bit.ly/agilecomms Face to face at a whiteboard
- 18. think sharp rmckergow Analysis is essential “Analysis doesn’t need a role to happen. But… the absense of a Business Analyst is not an excuse to ignore it.” Ryan McKergow
- 19. think sharp 3. The exciting parts of analysis: Techniques to try @ work
- 20. think sharp rmckergow Three amigos Given… When… Then…?
- 21. think sharp rmckergow Three amigos “A technique collaborative mindset involving the key functions in software development.”
- 22. think sharp rmckergow Three amigos Steps to be the three amigos: • Where ever you need to clarify a story talk to eachother at the same time • Time: 5-15 minutes • Other opportunities: • Sprint planning • Story kickoff • Demoing a story to the “business” (aka Product owner)
- 23. think sharp rmckergow Three amigos Additional information on the three amigos: http://bit.ly/3-amigos-atdd
- 24. think sharp rmckergow Three amigos I have a question … Me too! How can I help?
- 25. think sharp rmckergow Story kickoff
- 26. think sharp rmckergow Story kickoff “A technique to get a shared understanding of a story when starting development.”
- 27. think sharp rmckergow Story kickoff Steps to run a story kickoff: • Hold it when ready to start dev on a story • Gather the team & creator of the story • Ask the creator to visually explain the story & provide context • Asks lots of questions to clarify what they want • Start dev • Time: 5-15 minutes
- 28. think sharp rmckergow Story kickoff Additional information on story kickoffs: http://bit.ly/story-kickoffs
- 29. think sharp rmckergow Story kickoff
- 30. think sharp rmckergow Customer journey map
- 31. think sharp rmckergow Customer journey map “A technique to understand what our customers go through. What are their pains & what are the opportunities to improve?”
- 32. think sharp rmckergow Customer journey map Steps to create a Customer journey map: • Organise the team for a workshop (particularly someone involved in the existing process or a real customer!) • List out the: • Phases the customer goes through • What activities for each phase • What they gain / is painful about each phase • Brainstorm opportunities to improve on existing process • Time: 60-120 minutes
- 33. think sharp rmckergow Customer journey map
- 34. think sharp rmckergow Design studio workshop
- 35. think sharp rmckergow Design studio workshop “A technique to design the user interface together & identify gaps in our analysis.”
- 36. think sharp rmckergow Design studio workshop Steps to run a design studio workshop: • Organise the team for a workshop • Product owner provides context on new feature • Everyone draws what they think the interface will look like • Present to each other, share & critique ideas • Round 2 of drawing the interface based on feedback (optional) • Converge on a single design • Time: 30-90 minutes
- 37. think sharp rmckergow Design studio workshop Additional information on design studio workshops: http://bit.ly/design-studio-workshop (Details ¾ way down article)
- 38. think sharp rmckergow Design studio workshop
- 39. Don’t be a zombie reading your stories Learn the exciting parts of analysis Ryan McKergow ryanmckergow rmckergow
- 40. elabor8.com.au Thank you Ryan McKergow ryanmckergow rmckergow Slides: http://bit.ly/exciting-analysis
- 41. think sharp rmckergow Image References 1. Assets.nydailynews.com, (2016). [online] Available at: http://assets.nydailynews.com/polopoly_fs/1.98449.1314089135!/img/httpImage/image.jpg_gen/der ivatives/gallery_1200/gal-movie-a-team-jpg.jpg [Accessed 15 Feb. 2016]. 2. Ambysoft.com. (2016). [online] Available at: http://www.ambysoft.com/artwork/comparingTechniques.jpg [Accessed 28 Apr. 2016]. 3. Schiffer, B. (2015). Bernd Schiffer on Twitter. [online] Twitter. Available at: https://twitter.com/berndschiffer/status/611773018772103168 [Accessed 15 Nov. 2015]. 4. Agilemodeling.com, (2015). Communication on Agile Software Teams. [online] Available at: http://www.agilemodeling.com/essays/communication.htm [Accessed 15 Nov. 2015]. 5. Methodsandtools.com. (2016). [online] Available at: http://www.methodsandtools.com/archive/speccollab1.gif [Accessed 28 Apr. 2016].
Editor's Notes
- We’ve taken a look at how agile has changed organisations, but let’s deep dive into how it’s affected business analysts. Where do we fit in? Is there still a role for us? To investigate this, I want to take a look at the common roles within different agile teams.
- Business analyst, developers, testers, architect, product owner, project manager Business analyst acting as iteration manager (unless there’s a full time IM) Analysis is purely performed by the business analyst
- Business analyst (optional), developers, testers, product owner, delivery lead Business analysts are sometimes present in these teams. If they are, they lead the analysis. If not, analysis is the collective responsibility of the team.
- The Development team, Product Owner, Scrum Master Developers is the collective noun for all members of a cross-functional team. This could include business analysts, testers, architects, but all titled developers. This encourages T-shaped individuals. Specialisation in an area, but breadth in others. Emphasis that all specialisations are the collective responsibility of the team. This includes analysis.
- Developers, project manager Analysis is the responsibility of either the project manager or developers depending on company.
- So where does all of this leave us? Some teams have a Business Analyst… Some don’t? We need to be mindful of this and look at being flexible. Not caught up on a title, but looking to be a great T-shaped analyst. This leads to our last section...
- We’ve taken a look at how agile has changed organisations, but let’s deep dive into how it’s affected business analysts. Where do we fit in? Is there still a role for us? To investigate this, I want to take a look at the common roles within different agile teams.
- When the technology was simple – The way we thought about technology was also fairly simple. What are we building? Simple question right? A business analyst would gather the requirements to automate a manual process. The technology became more complex – There were suddenly more layers and complexity to think about, more servers, more databases, more connections. We needed more analysis on how all the systems would connect to each other. The technology became less complex – Or more accurately, we found better ways to manage the complexity of the systems. So the question was no longer about how are we going to build it, but why are we building it? Does it solve an existing problem in the market? Is there an appetite for a solution to the problem. In some ways, the complexity has now moved onto the interactions with users. So, the evolution of technology has changed the questions we ask.
- When the technology was simple – The way we thought about technology was also fairly simple. What are we building? Simple question right? A business analyst would gather the requirements to automate a manual process. The technology became more complex – There were suddenly more layers and complexity to think about, more servers, more databases, more connections. We needed more analysis on how all the systems would connect to each other. The technology became less complex – Or more accurately, we found better ways to manage the complexity of the systems. So the question was no longer about how are we going to build it, but why are we building it? Does it solve an existing problem in the market? Is there an appetite for a solution to the problem. In some ways, the complexity has now moved onto the interactions with users. So, the evolution of technology has changed the questions we ask.
- When the technology was simple – The way we thought about technology was also fairly simple. What are we building? Simple question right? A business analyst would gather the requirements to automate a manual process. The technology became more complex – There were suddenly more layers and complexity to think about, more servers, more databases, more connections. We needed more analysis on how all the systems would connect to each other. The technology became less complex – Or more accurately, we found better ways to manage the complexity of the systems. So the question was no longer about how are we going to build it, but why are we building it? Does it solve an existing problem in the market? Is there an appetite for a solution to the problem. In some ways, the complexity has now moved onto the interactions with users. So, the evolution of technology has changed the questions we ask.
- When the technology was simple – The way we thought about technology was also fairly simple. What are we building? Simple question right? A business analyst would gather the requirements to automate a manual process. The technology became more complex – There were suddenly more layers and complexity to think about, more servers, more databases, more connections. We needed more analysis on how all the systems would connect to each other. The technology became less complex – Or more accurately, we found better ways to manage the complexity of the systems. So the question was no longer about how are we going to build it, but why are we building it? Does it solve an existing problem in the market? Is there an appetite for a solution to the problem. In some ways, the complexity has now moved onto the interactions with users. So, the evolution of technology has changed the questions we ask.
- When the technology was simple – The way we thought about technology was also fairly simple. What are we building? Simple question right? A business analyst would gather the requirements to automate a manual process. The technology became more complex – There were suddenly more layers and complexity to think about, more servers, more databases, more connections. We needed more analysis on how all the systems would connect to each other. The technology became less complex – Or more accurately, we found better ways to manage the complexity of the systems. So the question was no longer about how are we going to build it, but why are we building it? Does it solve an existing problem in the market? Is there an appetite for a solution to the problem. In some ways, the complexity has now moved onto the interactions with users. So, the evolution of technology has changed the questions we ask.
- Another big change in the last 15 years – and the reason we’re all here today - is the introduction of an agile way way of working. There are some key improvements that agile methodologies have brought to organisations, I want to highlight three of the big ticket items, to show that the teams and processes around the role of business analyst have also been evolving.
- In development teams, you can easily make a significant difference to team performance. There are a number of things you can do to help support this: Help to work for consensus on decisions and features to be built, involve the whole team in the decision-making process where possible. Developers love solving problems, let them help come up with the solutions. This will encourage greater engagement and ownership of the issue/product. When I worked at Sensis I was working on optimizing a feature and we were just struggling to come up with a fantastic solution that would delight our users, when I started involving the developers, that’s when things got really interesting. We ended up with a solution that was more interesting, looked great and the whole team felt like they helped make the decision and were super happy with the outcome. Have a shared understanding of project goals and ambitions. You can help with this by communicating proactively. If decisions are made by the business, ensure these decisions are communicated back to the development team. If the dev team understands the goals and reasons behind those goals, they will make the right decisions when it comes to developing features. For example, I worked at an organisaation where there was a business decision to deprioritise a whole lot of functionality in order to deliver an MVP to users. Unfortunately this wasn’t communicated properly back to the development team and they continued working on features that were no longer a part of MVP. So make sure that if the goals have changed, that the team are told and that they understands the reasons for the change, we’re all in this together after all. Effective teams possess not only technical skills, but also emotional intelligence. It turns out that if individuals on your team are socially aware, the whole group puts in better quality work. The ability to understand the feelings and thoughts of others—is one of the most important factors that can influence overall team intelligence. One of the easy things you can do for this one, is never assume your team mates life outside of work is great. Because it may not be, if you take the time to ask questions and get to know every member on your team, you will find that the team will start to collaborate and actually enjoy coming to work more, as they will feel understood. Also, humor. It might not be such an obvious factor in the effectiveness of a team, but actually humor inspires trust and intimacy—which can lead to overall better team interactions. SO don’t be afraid to be a bit of a clown, or to tell that cheesy dad joke. It will put everyone at ease, and who knows, you may actually enjoy coming to work if you have fun there. Remember, great teams don't just happen. Teams fit together like puzzles and are the result of hard work.