A strong leader in quality is someone who can say a NO in a convincing way and help the stakeholders understand why a decision endangering quality cannot be encouraged.
Transport management and testing
Quality is not just testing although this is a common superstition. In the teams that i come across, when people talk of product quality, the most common aspect they kind of communicate is clearly that we need to test more. The average age of the team is about 5 years, the guys have done a lots of projects together then why is this a common understanding?
Are the other practices effective even if being followed? How frequently have we seen a development team say that pair programming and test driven development effective and informative? For sure, i have not yet seen one such team atleast till now. Have we ever wondered how much of defects get delivered to customer which could have been found locally? Have you seen how frequent are your transport releases and at which points do they come?
Without these, can a lean practice be called lean?
Are the other practices effective even if being followed? How frequently have we seen a development team say that pair programming and test driven development effective and informative? For sure, i have not yet seen one such team atleast till now. Have we ever wondered how much of defects get delivered to customer which could have been found locally? Have you seen how frequent are your transport releases and at which points do they come?
Without these, can a lean practice be called lean?
Lets not forget the criticality of transport management in quality control
In my perspective, one of the most important areas which a quality personnel should take control is the landscape and how the code transport happens between them. Its amazing to see that being such a critical topic how is it even possible to under estimate the control over the same. Yet, as a software tester, we often dont spend time to understand how the developers write code and what are the quality processes which happen once the code is checked into the dev landscape.
When the scrum team doesn't pull the chain
In the scrum meeting:
Hari : Yesterday, I was working on integrating the console with services. Today, i will continue to integrate. No blockers as of now.
Jagan : Sounds great. However, wasn't this be the case yesterday as well?
Hari : Yes. The story is complex and the UI implementation got some feedbacks of late which had to be implemented.
Jagan : Ok. Are there any revisions made in the screen?
Hari : The parsing algorithm done as part of sprint had introduced a fresh thought and these changes were requested.
Jagan : However, how can algorithm be done when its not a planned item?
This is a familiar situation scrum masters will come across particularly when the team is empowered to make decisions. Scrum masters should encourage the team to pull the chain and stop the production when the done criteria changes or when scope creep is tried.
Hari : Yesterday, I was working on integrating the console with services. Today, i will continue to integrate. No blockers as of now.
Jagan : Sounds great. However, wasn't this be the case yesterday as well?
Hari : Yes. The story is complex and the UI implementation got some feedbacks of late which had to be implemented.
Jagan : Ok. Are there any revisions made in the screen?
Hari : The parsing algorithm done as part of sprint had introduced a fresh thought and these changes were requested.
Jagan : However, how can algorithm be done when its not a planned item?
This is a familiar situation scrum masters will come across particularly when the team is empowered to make decisions. Scrum masters should encourage the team to pull the chain and stop the production when the done criteria changes or when scope creep is tried.
Subscribe to:
Posts (Atom)