Chicago, IL USA
Abby Bangser has been working as a Quality Analyst with ThoughtWorks since 2012 with key interests in bridging the gap between the different development team roles and growing the QA community. Experiences include crafting and delivering both internal and external training programs as well as a diverse portfolio of client work. Before coming to ThoughtWorks Abby worked in real estate investments and she continues to stay active in youth lacrosse coaching.
As a tester on an agile team, you’ve probably experienced at least one of these scenarios:
Someone sitting right next to you asked you a question via email
At the end of a standup, you realized you had no idea what your teammate is working on
You test a story that the developers have marked finished, and are dumbfounded to find that some explicit Acceptance Criteria were completely missed
Over the past several years, Abigail Bangser has worked on over five different teams where she experienced these and many more examples of how we can get into the trap of “doing” agile rather than “being” agile. While this may be a cliché, it is a very real trap! It’s particularly precarious for testers moving from end-of-lifecycle test groups to co-located, cross-functional teams.
In this session, Abby will share some fun (and sometimes embarrassing) stories that highlight these behaviors. She will explain how she and her teammates have learned to identify and shift their teams’ behaviors over time to “be” rather than just “do” agile, working together to build quality into their software product. Participants will take away practical ideas and techniques to help them collaborate with their whole delivery team.
Ideas for encouraging effective collaboration
Identify the most effective retrospective style for a given team and time
Communicate how certain metrics may be driving less desired team behaviors
In an agile environment of quick project starts and even quicker deadlines, teams are being asked to deliver value to customers faster. Our team succeeded in delivering all the requested business value in time, but still had a huge hurdle to jump at the end - actually releasing the product to our customers!
Businesses think that they do not need to know (or care) about the “technical” decisions of their teams, such as how a product will actually be released, or how the release procedure itself will be tested. This is not only wrong; it is dangerous for the company's bottom line. When technical release decisions are contained in a technical team silo, we are only using half our teams’ skills and risking delivery to our end users.
We all know managers do not just want problems raised; they want solutions proposed. Learn to clearly articulate delivery risks to the business and also mitigate the risks through proven practices applied in new ways.
- Clearly articulate delivery risks to businesses when technical decisions are in a separate silo from business decisions
- Leave with concrete ways to mitigate risks through proven practices applied in new ways