Business Driven Quality in Scaled Agile Teams
Evolving an organization to use more agile techniques often means re-evaluating the role of dedicated QA teams common in waterfall development processes. In software organizations that develop a large platform with a group of agile development teams, there is still a need to ensure quality at a product and platform level. As one solution to this, this talk introduces the idea of Platform QA, a dedicated team of QA specialists with responsibility to the entire product, and the platform that delivers it. Platform QA is a feature team that works on a backlog of quality risks and has ultimate ownership of shared artifacts such as end to end (BDD) tests and QA environments. This talk discusses differences between waterfall QA, platform QA and embedded QA, examples shared from my own experience, and conditions where this solution may make sense as a transitional or target organizational structure.
Outline/Structure of the Experience Report
- Agile and Large Scale Scrum ideas of Product
- Expansive product definition
- One product built by one team on a shared backlog
- Business Driven Development tests as product definitions
- Bratton definition of platform (from The Stack)
- Platform as the system(s) that deliver the product
- Three team structures for quality
- Waterfall QA
- Embedded QA
- Platform QA and Tools relationship
- Platform QA as a transition or a destination
- Stealth or bottom-up transition
Recognize scale / co-ordination problems and some Large Scale Scrum solutions to that
Identify different QA structures, and understand the tradeoffs involved
Testers, Managers, Developers, anyone interested in team structure and quality
Prerequisites for Attendees
Familiarity with Agile techniques and terminology at an introductory or intermediate level. Working in a large organization. Testing software, their's or others'.
schedule Submitted 1 year ago
People who liked this proposal, also liked:
Vered Netzer - agile Leadership - why the army is the most agile organisation I've ever been inVered NetzerTransformation LeaderThoughtWorks
schedule 1 year agoSold Out!
It is time to talk about ‘agile Leadership’.
Reflecting on 7 years of experience in the Israeli army I’ll be sharing stories and insights about how the army REALLY operates.
The army is not as ‘Command & Control’ as people commonly expects – it is much more empowering and agile than you’d think.
At the army, I’ve learnt the true meaning of cross functional teams, the importance of reflection, feedback, creative problem solving, trust, teamwork, conflict resolution, resilience & responding to change.
This talk will be intertwined with army (and civilian) war stories & tips for leaders in an agile world. This talk aims to inspire a new wave of Agile Leaders, through sharing examples of effective leadership, it draws on real, lived experiences and concepts (directly from the ‘horse mouth’) as well as useful takeaways that attendees can take back and apply to their work.
Adam Burke - Building Memory Palaces From Ontological SlimeAdam BurkeSoftware Critic, Electronic TradingBank of America Merrill Lynch
schedule 1 year agoSold Out!
Software is complex and made from slime.
It is complex both in the everyday sense, and in the more technical sense used by complexity science. It is slime in that software is continually forced to engage with real world systems very unlike the laws of highschool physics, systems where rules are very local and contingent. William Wimsatt calls this "ontological slime".
This complexity is why agile software development and design are effective, including the usefulness of human feedback and of reducing localised complexity in code. We also have an agile idea, from Peter Naur, that a large part of programming is building and improving a model of the system in the programmer’s head. What does that imply about the worldview of an effective programmer? Because software is a complex system, a great developer needs survival techniques for navigating and building beautiful machines out of causal thickets and ontological slime.