Don't be a zombie writing your stories - Brisbane BA Meetup - 14-06-2016
•Als PPTX, PDF herunterladen•
3 gefällt mir•1,341 views
Have you ever been told that all Business Analysts do on Agile projects is write stories? I have... and that's the boring part of our job! There are lot of exciting analysis techniques we can use to not only elicit requirements, but have fun and collaborate with others while doing so. During this talk, you will learn about why problem solving with our software development teams is essential. I will introduce techniques to get our teams talking, discussing the problem, and agreeing on a solution. Learn how to run a design studio workshop, facilitate a customer journey map or hold a story kickoff. I'll also include general facilitation tips to take these session up another notch. Don’t just be a zombie writing your next story. Let’s think about the problem and how we’ll solve it together!
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von Ryan McKergow
Mehr von Ryan McKergow (15)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Don't be a zombie writing your stories - Brisbane BA Meetup - 14-06-2016
- 1. Don’t be a zombie writing your stories Learn some exciting analysis techniques Ryan McKergow ryanmckergow rmckergow
- 2. think sharp rmckergow Business Analysts just write stories in agile right?
- 3. think sharp 1. We’re more than just story writers… Analysis is essential
- 4. 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
- 5. 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
- 6. think sharp rmckergow T-shaped individuals Breadth Depth
- 7. think sharp rmckergow Poll: Can you relate? development team
- 8. 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
- 9. 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
- 10. think sharp rmckergow Analysis and critical thinking is essential “Our job as analysts is not just to write requirements.” Ryan McKergow
- 11. think sharp 2. The exciting parts of analysis: Techniques to try @ work
- 12. think sharp rmckergow Three amigos Given… When… Then…?
- 13. think sharp rmckergow Three amigos “A technique collaborative mindset involving the key functions in software development.”
- 14. 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)
- 15. think sharp rmckergow Three amigos Additional information on the three amigos: http://bit.ly/3-amigos-atdd
- 16. think sharp rmckergow Three amigos I have a question … Me too! How can I help?
- 17. think sharp rmckergow Story kickoff
- 18. think sharp rmckergow Story kickoff “A technique to get a shared understanding of a story when starting development.”
- 19. 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
- 20. think sharp rmckergow Story kickoff Additional information on story kickoffs: http://bit.ly/story-kickoffs
- 21. think sharp rmckergow Story kickoff
- 22. think sharp rmckergow Customer journey map
- 23. 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?”
- 24. 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
- 25. think sharp rmckergow Customer journey map Phase Activities Gains Pains Opportunities
- 26. think sharp rmckergow Design studio workshop
- 27. think sharp rmckergow Design studio workshop “A technique to design the user interface together & identify gaps in our analysis.”
- 28. 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
- 29. think sharp rmckergow Design studio workshop Additional information on design studio workshops: http://bit.ly/design-studio-workshop (Details ¾ way down article)
- 30. think sharp rmckergow Design studio workshop
- 31. think sharp Tips to facilitate great workshops
- 33. think sharp elabor8 Facilitate with intent
- 34. think sharp elabor8 Encourage appropriate behaviours
- 35. think sharp elabor8 Engagement from everyone
- 36. Don’t be a zombie writing your stories Learn some exciting analysis techniques Ryan McKergow ryanmckergow rmckergow
- 38. 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].
Hinweis der Redaktion
- 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.
- Facilitating a workshop well can mean that your workshops are no longer unproductive. How do you do this… Designated facilitator (preferably not a participator) Be clear and confident with instruction of how to run the technique – State your expectations of people Have enthusiasm! It’s important to bring energy to the room – Think about how you would normally facilitate or lead a meeting – Now take the energy up a level or two! Explain and enforce the agenda or if it is a Retro – the format chosen
- Enforcing the appropriate behaviour within workshops is important to ensures two things: 1. It ensures the Retro is respectful. 2. It does not turn into a blaming session that will not help anyone. Respectful Turning up on time – avoid distractions later Not talking over the top of eachother (VERY important in Distributed Retros) Including everyone – people in distributed teams & quiet people Positives Focus on the positives How we can help eachother (not just focus on our individual roles) How can we work together
- 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.