Scrum and agile: The perception influencers
Not many years ago, when Agile and Scrum were introduced, they set off a wave of change in the industry.
Scrum had three roles defined – the Product Owner, the Scrum Master, and the Scrum Team.
While the Scrum Master and Product Owner roles were easier to understand, it became difficult to define what Scrum Team was. More so, as the members of the team were supposed to be cross-functional, having all the skills necessary to form a cohesive, self-organizing unit. The Scrum Team had defined ‘developers’ as those who have the responsibility to instill quality in software, by adhering to the definition of ‘Done’.
There was no definition for ‘testers’ and it appeared that the responsibility for quality was delegated to the ‘developer’. The idea behind having a Scrum Team and the developer role, in particular, was to bring efficiency to the team and to discourage any specialized roles. It meant that the same developer would wear the hat of a business analyst, tester, designer, etc. as the team demands.
The justification and relevance
Our understanding of the Scrum Team and the developer’s role has evolved over the years. However, we still continue to be challenged by misconceptions surrounding the developer’s role in testing and the need to eliminate the role of the tester – be it within Scrum Teams or in traditional projects. This topic becomes relevant now as we have a sprawling start-up culture, where such ideas are encouraged.
We recall an experience when one of our customers, a growing start-up, required developers to take on the role of testers.
They had a development team that largely followed an unstructured development process. There were no testers in the team and the developers had the autonomy to make the changes as needed. The bugs were sometimes being fixed in the production environment, even at the cost of crashing the production systems. Some justifications for these decisions were:
- Testing was considered the responsibility of developers
- Introducing test engineers would slow down development cycles
- No funds to add test engineers to the project
Double-hatting implications
When our developers were engaged to augment the customer team’s capacity, we had an interesting challenge on hand. Our developers were trained to perform unit and integration testing but relied on testers to carry out the functional and non-functional testing.
As the customer insisted on the ‘No Tester’ culture, we had no option but to follow their defined processes. However, by the end of the first release, we realized a few things. Our developers’ productivity was taking a hit, so much so that the team velocity was going downhill.
The developers had to stretch and put in long hours to complete the committed deliverables. But, more importantly, there were quality issues identified in the release build. While we were extremely concerned with our team’s performance, the customer seemed to empathize with our team and seemed okay with both the productivity and quality of deliverables. We later realized that their development team was also having a similar experience. Our team, however, was getting burnt out and feeling demoralized with the outcome.
Back to the basics
After retrospection, and after discussing with the customer, we decided to introduce testers on an experimental basis, to support our team, at no additional cost. The testers worked in sync with the developers to provide both ad-hoc as well as structured testing, based on the test cases that were reviewed and approved by the customer.
The developers, on the other hand, were focused on building features, performing unit and integration testing at their level, and fixing errors reported by the testers. The outcome of the 2nd release was a big surprise. The team velocity had climbed sprint-on-sprint and they were able to commit and deliver 30% above their initial productivity.
There were no critical or major defects in the release build. Moreover, documented defects were available for root cause analysis and charting out future action plans. The result was encouraging enough for the customer to include testing support for their own development teams as well.
Summarizing our conclusions
Our experience has taught us that:
a). Developers tend to lose focus when they multitask. Multitasking is a classic form of Muda, or wasted effort. It happens when people, systems, or machines frequently switch between contexts. Therefore, as far as developer testing is concerned, it must remain confined to unit and integration testing.
b). The additional cost of adding testers to the team can be justified by improved quality and an increase in the overall productivity of the team. While the disciplined approach may slow down the process initially, it will eventually help improve productivity as a result of reduced rework.
c). Testing is a specialized skill that is honed over the years and mustn’t be taken lightly. It involves several additional tasks that cannot be expected from a developer such as maintaining the sanctity of the QA environment, identifying alternate test scenarios, creating test data, systematically documenting defects and publishing reports, and most importantly, the zeal to find defects without any confirmation bias.
What’s your experience? We’ll be happy to hear which points you agree with and which ones you don’t. In case you have other reasons to believe that developers should be taking over testing, please write to us at itservices@healthasyst.com
<a href=’https://www.freepik.com/photos/business’>Business photo created by pressfoto – www.freepik.com</a>