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

  1. Agile and Large Scale Scrum ideas of Product
    1. Expansive product definition
    2. One product built by one team on a shared backlog
    3. Business Driven Development tests as product definitions
  2. Platform
    1. Bratton definition of platform (from The Stack)
    2. Platform as the system(s) that deliver the product
  3. Three team structures for quality
    1. Waterfall QA
    2. Embedded QA
    3. Platform QA and Tools relationship
  4. Platform QA as a transition or a destination
    1. Stealth or bottom-up transition

Learning Outcome

Recognize scale / co-ordination problems and some Large Scale Scrum solutions to that

Identify different QA structures, and understand the tradeoffs involved

Target Audience

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

Public Feedback

comment Suggest improvements to the Speaker
  • Joel Tosi
    By Joel Tosi  ~  1 year ago
    reply Reply

    Hi Adam, thanks for the submission.  It is interesting, and while I personally wonder if this is a solution to a symptom or a solution to a problem, I think it is worth exploring

    I like these aspects of the submission, and they should be retained:

    • Good explanation of different options, where they fit, what to look for

    I think the submission could be improved by:

    • I struggle with if, after attending this session - I could make a decision or would have something to try.  I'm missing that bridge between ' interesting observation' and 'try this Monday at work'

    Could you help with the latter?



    • Adam Burke
      By Adam Burke  ~  1 year ago
      reply Reply

      Hi Joel

      I've put up a blog post on Platform QA


      Appreciate the talks for the conference are long ago closed, but if you were curious about it, this provides some more detail.



    • Adam Burke
      By Adam Burke  ~  1 year ago
      reply Reply

      Hi Joel

      Thanks for the thoughtful comments and perceptive question.

      I think this is a solution that applies when there is
      + A large organization of multiple software teams
      + Delivering a single product
      + Needing greater coherence and quality across systems and teams
      + Over a medium- to long-term period
      + Avoiding putting in place heavy project-management overhead at that product/platform layer

      On the specific evolution we went through - we went from waterfall, then embedded, then to platform QA. We were organized around component teams (the definition of components broadened over time). This supported a growth path through little or poor test automation (under waterfall), much more investment in component-level tests (embedded QA), to shifting to a maintenance and improvement relationship with component and integration automated tests.

      Organizationally, we shifted over time to a product/platform view and a more explicit product owner - but we never had buy-in from upper levels of management to implement practices like LeSS or feature teams as a sudden shift. (I suspect this isn't unusual.)

      I do feel that this is a solution that applies to particular circumstances, and don't want to overgeneralize from one organization, or propose it as a panacea. I even wonder whether some of the coherence and platform-focus problems it addresses would be lesser in other processes and contexts, but also that these are common problems. I have seen similar dynamics in shifts to feature teams (tragedy of the commons), and I also think it manages that shift.

      There are some similarities with team structures described in the "Google Way of Testing", which seem very google-specific, lack the product aspect, and also I haven't worked there. There are also a lot of organizations with traditional QA end-of-lifecycle teams that could benefit from reconceptualizing what QA is. Lastly I think this help incrementally teach an organization that they deliver a product, by creating specific artifacts that describe that product (the BDD tests) and people aligned with its delivery by a platform.

      Hope that helps

  • Liked Talia Lancaster

    Talia Lancaster / Angie Doyle - T-minus 10… 9… 8… We have lift-off!

    90 Mins

    Getting new teams to work together is hard. Really. Hard.

    Is it because there is so much hype around new Agile teams? Or is it because there is such a focus on “doing things right” (or “doing” Agile right), that we forget about the people actually doing the work? Regardless of the reason, before we can change the way people work... we need to focus on the things that are important for teamwork to work!

    We believe that the key to high-performance teams is creating an intentional culture that respects and embraces diversity - whether it be race, gender, class, culture, age, beliefs, language, skills or background. So join us as we explore the Team Canvas – sort of like a Business Model Canvas for teamwork - covering nine essential teamwork elements:

    • Purpose - Why we are doing what we are doing?
    • People & Roles - What are our names, roles and responsibilities?
    • Common goals - What do we as a group want to achieve together?
    • Personal goals - What do I as an individual want to achieve?
    • Team values - What do we really stand for and believe in?
    • Needs and expectations - What do each of us need to be successful in a diverse team?
    • Rules & Activities - How do we communicate and keep everyone up to date?
    • Strengths & Assets - What skills do we have in the team?
    • Weaknesses & Risks - What are the weaknesses we have, as an individual and as a team?

    We will walk through our agenda for team lift-offs, facilitation posters and preparation work required, materials needed, and facilitation tips and tricks. All packaged in a handy pocket guide, that you can use to explore tried and tested techniques for each essential element. We will also have an opportunity to practice some of these techniques during the session.

    Get ready to lift-off your team in T-minus 10... 9... 8...

  • Liked Vered Netzer

    Vered Netzer - agile Leadership - why the army is the most agile organisation I've ever been in

    20 Mins

    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.

  • Liked Adam Burke

    Adam Burke - Building Memory Palaces From Ontological Slime

    45 Mins

    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.

  • Liked ShriKant Vashishtha

    ShriKant Vashishtha - Watch-out for Agile Transformations with Waterfall Mindset

    ShriKant Vashishtha
    ShriKant Vashishtha
    Agile Coach
    schedule 1 year ago
    Sold Out!
    45 Mins

    This session helps in understanding problems when teams move towards Agile but leadership is still stuck with waterfall mindset. It also helps in understanding why Agile transformations fail.

    Even after making transformation efforts for multiple years, in many enterprises, people start doing Agile "process" eventually. But the whole setup, organisational culture, hierarchy, siloed mindset, delays across departments remain same. Even after spending millions, the benefits remain negligible. The enterprise doesn't become agile enough in coming out with innovation and anticipating disruptive changes in the market

  • Liked ShriKant Vashishtha

    ShriKant Vashishtha - Collaborative Daily Scrum : A Collaborative Alternate to 3 Questions Based Daily Scrum

    ShriKant Vashishtha
    ShriKant Vashishtha
    Agile Coach
    schedule 1 year ago
    Sold Out!
    20 Mins

    The 3 questions based Daily Scrum is the defecto way of doing Daily Scrum across teams. For years people have been finding it inadequate as it tends to focus on individuals rather than team and sprint goal, promotes status update kind of discussion rather than collaborative sync-up and becomes an accomplice in promoting zombie Scrum.

    The 3 questions based Daily Scrum, unfortunately, doesn’t require collaboration as a mandatory prerequisite. Without mandatory collaboration, no team becomes self-organized as the Development Team continue to be dependent on someone like Scrum Master to organize them as a team.

    In 2017 update of Scrum guide, because of all these reasons, 3 questions based Daily Scrum became one of the many Daily Scrum implementations.

    However in the absence of any better alternate, people continue to use 3 questions based Daily Scrum.

    This alternate implementation of the Daily Scrum, called Collaborative Daily Scrum considers collaboration (pair programming, swarming or mob programming) as the mandatory aspect of the Daily Scrum. The focus is on sprint goal and working as a team and not on individual updates anymore. At any point of time, the team plans to finish at most 2-3 stories collaboratively which helps in automatically limiting the WIP on the Scrum Board.

    This implementation has been well received which was published through an AgileBuddha blog post. The post includes the inputs from James Coplien (inventor of daily standup).