Bharat JainProgram Manager| DigiValetIndore, Mp, India
A Platform being developed that supports multiple products. Each Product is of a different vertical with different personas but functionally the same modules. How should the Development and Quality Assurance team be divided? Please share justifications. Should the Development team be assigned to Platform while the QA team is distributed Product-wise? Pros and Cons? Saving Changes...
I'd start by asking why you are separating dev & QA teams? Handoffs and handbacks are a common source of waste so why not have teams composed of all the skills needed to deliver work items end-to-end?
In your scenario, it is common to have one team responsible for "framework" or foundational type work which establishes a common set of components shared by the other teams who will deliver the distinct products.
Kiron
...
1 reply by Bharat Jain
Jan 08, 2024 8:40 PM
Bharat Jain
...
Let me help explain the situation more accurately. The platform being developed is used to support multiple products. These products are for different verticals. Each product comprises of the Saas platform along with a mobile offering pertaining to the product and not the platform. So essentially platform QA and Dev are separate while product QA and Dev are separate. The challenge here is how to manage quality of the platform as today I do not have platform QA which I am planning to propose. I also want to avoid too much redundancy on part of QA since the features would be tested when used in a product.
I hope I was able to describe the problem more elaborately.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Bharat, I don't have much more to add to what Kiron already mentioned. If it was me, I would have a common team for the framework because handoffs can be a real pain and source of waste and could be a source of loss of information sometimes. Saving Changes...
Bharat JainProgram Manager| DigiValetIndore, Mp, India
Let me help explain the situation more accurately. The platform being developed is used to support multiple products. These products are for different verticals. Each product comprises of the Saas platform along with a mobile offering pertaining to the product and not the platform. So essentially platform QA and Dev are separate while product QA and Dev are separate. The challenge here is how to manage quality of the platform as today I do not have platform QA which I am planning to propose. I also want to avoid too much redundancy on part of QA since the features would be tested when used in a product.
I hope I was able to describe the problem more elaborately.
Saving Changes...
Bharat JainProgram Manager| DigiValetIndore, Mp, India
Jan 08, 2024 7:13 AM
Replying to Kiron Bondale
...
Bharat -
I'd start by asking why you are separating dev & QA teams? Handoffs and handbacks are a common source of waste so why not have teams composed of all the skills needed to deliver work items end-to-end?
In your scenario, it is common to have one team responsible for "framework" or foundational type work which establishes a common set of components shared by the other teams who will deliver the distinct products.
Kiron
Let me help explain the situation more accurately. The platform being developed is used to support multiple products. These products are for different verticals. Each product comprises of the Saas platform along with a mobile offering pertaining to the product and not the platform. So essentially platform QA and Dev are separate while product QA and Dev are separate. The challenge here is how to manage quality of the platform as today I do not have platform QA which I am planning to propose. I also want to avoid too much redundancy on part of QA since the features would be tested when used in a product.
I hope I was able to describe the problem more elaborately.
...
1 reply by Kiron Bondale
Jan 09, 2024 7:08 AM
Kiron Bondale
...
Bharat -
I would still strongly recommend not splitting the Dev and QA functions for each component into separate teams as neither delivers customer value by itself. The focus of the QA function for platform is different than for product - the former is likely to be more systems/integration type verification whereas the latter would be more functional acceptance type verification so the coverage should naturally be somewhat different.
Bharat,
I think you are wise to add platform level QA. What you are describing is similar to many programs where there is some base product with different unique instances developed by separate teams for different customers. Having representation for development and QA at the program level helps keep things consistent between individual projects, to share lessons learned, best practices, risks, etc.
It does not necessarily need to be a high level of effort at the program or platform level, but integrating all functions at that level often has significant benefits across all projects. Saving Changes...
Let me help explain the situation more accurately. The platform being developed is used to support multiple products. These products are for different verticals. Each product comprises of the Saas platform along with a mobile offering pertaining to the product and not the platform. So essentially platform QA and Dev are separate while product QA and Dev are separate. The challenge here is how to manage quality of the platform as today I do not have platform QA which I am planning to propose. I also want to avoid too much redundancy on part of QA since the features would be tested when used in a product.
I hope I was able to describe the problem more elaborately.
Bharat -
I would still strongly recommend not splitting the Dev and QA functions for each component into separate teams as neither delivers customer value by itself. The focus of the QA function for platform is different than for product - the former is likely to be more systems/integration type verification whereas the latter would be more functional acceptance type verification so the coverage should naturally be somewhat different.
Kiron
...
1 reply by Bharat Jain
Jan 09, 2024 10:48 AM
Bharat Jain
...
Thanks Kiron. Should having QA segregated product wise as well as a dedicated team for platform be more value add. The aim for the platform as you suggested, would be more systems/integration type verification while the product QA is determined to deliver customer value.
Saving Changes...
Bharat JainProgram Manager| DigiValetIndore, Mp, India
Jan 09, 2024 7:08 AM
Replying to Kiron Bondale
...
Bharat -
I would still strongly recommend not splitting the Dev and QA functions for each component into separate teams as neither delivers customer value by itself. The focus of the QA function for platform is different than for product - the former is likely to be more systems/integration type verification whereas the latter would be more functional acceptance type verification so the coverage should naturally be somewhat different.
Kiron
Thanks Kiron. Should having QA segregated product wise as well as a dedicated team for platform be more value add. The aim for the platform as you suggested, would be more systems/integration type verification while the product QA is determined to deliver customer value. Saving Changes...
"Far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly 98 million miles is an utterly insignificant little blue-green planet whose ape-descended life forms are so amazingly primitive that they still think digital watches are a pretty neat idea..."
Community Champion
