Stuck in a non cross functional team - HELP !
Before you guys begin to read this, my org has the following setup, wherein we have a dedicated QA aligned to the project. team strength: 5.5 developers and 1 QA. This is what makes my scrum team. This cant be changed, so please advise accordingly. Also, my project is a high priority project in the org. I am unable to follow any scrum process there. Please help.
1) Is the dev : a ratio is fine ? In my opinion, the kind of development my 5.5 devs does, i don't think can be testable by 1 QA
2) usual sprint backlog:
Story 1 = Pointer A (dev and testing effort inclusive)
Story 2 = Pointer B (dev and testing effort inclusive)
Story 3 = Pointer C (dev effort only)
Story 4 = Pointer D (dev effort only)
Story 5 = Pointer E (dev effort only)
The reason why story 3/4/5 are dev stories, because my testing bandwidth has been exhausted. Those first two stories from the testing side are equivalent to good 20 pointer effort. I know, we should be not be distinguishing a dev and an effort but that's the way it is. My tester says that he has to do QA analysis and then document the test cases and then execute them, hence the testing effort is on the higher side.
please help me, ho to coach the team to think from the story as a whole and not from dev and qa stand point. also, if i create all stories as testable, majority of them will head to a spill over. Please help me, i also want if i can speak to someone over a zoom or a phone call to address my issues. :(
This cant be changed, so please advise accordingly.
@Rhea Pillai, If you have just $1 and you can't make more money and you want to buy something worth $1000, is that even possible?
Have you considered that Scrum is exposing the problems you are having? Also, if this is your reality in the organization, then what is the motivation or the need to use Scrum?
Happy to connect over Linkedin.
My advice is to start with the Scrum values, and the determination that things can change, instead of just being the way it is.
QA is more than testing. It is also the activity of making things higher quality. I have lived with your situation for many years and have always been able to address the problem. Each time it was in a different manner because it will depend on the team to decide what is best for their specific situation. But there have always been some common elements. They are:
- The QA representative has to be thought of as more than a tester.
- The Developers have to realize and accept that they play a part in the quality of the product
- The team has to stop using the waterfall approach of developers code, qa tests
Let me explain the bullets in terms that your team can use.
QA representatives can be useful in preventing bugs from occurring instead of just finding the bugs. By participating in the refinement of the stories, they can start to ask questions from a behavorial (user) perspective that can help to influence design decisions and aid the developers in thinking of usage scenarios.
Developers actually own a large part of the testing effort. If you are familiar with the Testing Pyramid you will understand that the largest layers are owned by the developers and are using automated testing efforts. They should be held accountable for delivering those tests and then the QA can validate from the end-to-end perspective using existing coverage to limit the amount of testing that they need to do. Adequate coverage by unit, integration, system, API level automated testing gives faster feedback to the developers and will also serve as an indicator that their changes have impact outside of the expected boundaries. Each code review should include the review of developer provided automated test coverage. If tests are not added, modified, removed for any code change then the code is not complete.
The development team needs to get faster feedback and turnaround of their changes. If they write code for Story A, put it into the QA queue and start working on Story B, when QA finally gets to test and finds a bug they will have to context switch back to Story A. This context switching is a big time waste and can also lead to fixing a bug but introducing others. The best time to fix a problem is when they are actively working on the solution and have their entire thought process involved. So immediate feedback is essential. For this see the above reason about automated testing.
The problem that your team is having isn't about not having enough QA Engineers on your team. It is that your team does not understand the concept of quality. Succesful teams stop thinking about quality assurance and shift to thinking about quality ensurance. Assurance happens after work is done, ensurance starts before work begins.
I'm more concerned about the fact that there is a difference between the software engineer, and the tester. Why can't the developers test each other's work? Why do test cases have to be extensively documented?