A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.

Audible

How to Go Fast and Not Get Buried in the Dust

Agile model changed the way we deliver software. It requires more than adopting new processes like Scrum and DevOps - it requires a complete mind shift. While delivering software in small increments and receiving continuous feedback from customers have provided significant improvements over the traditional waterfall (6 months to a year) delivery, like any groundbreaking, life-saving medicine, it came with few non-trivial side effects. The biggest potential victims of Agile are Quality and Technical Debt.

Maintaining quality while delivering shippable software in a 2-4 week time period is an obvious challenge that most companies shifting towards Agile have to face. In a traditional waterfall model, software used to spend a large chunk of the overall delivery time in Quality Assurance. QA was a rather large centralized team that allocated resources to each project, which in turn went thru multiple iterations of testing, bug fixing, and re-testing. In the waterfall model, the software could not be released to production without an official QA signoff which means that all reported bugs have either been fixed, accepted by the business as working as designed or deferred until the next release. In Agile, an ideal Scrum team should consist of developers and testers, and story points should not be claimed unless the story has been developed and tested. However, in reality, teams often spend full sprint coding, and testing either happens on the last day of the sprint or gets pushed to the next sprint, which puts the testers one sprint behind the rest of the team.

In several companies that I used to work at, there was a concept of “Done*” (Done Star), which meant that the story was completed but not tested. This concept allowed the Scrum team to claim the Story points and meet their Sprint commitments. Testing should be thoroughly embedded into the “Definition of Done” which includes unit, functional, integration and performance to address this undesired side effect of Agile. In addition, every sprint should allocate time for test automation without which regression testing in the Agile delivery model would not be possible. And finally, all members of the Scrum team should be willing and able to pick up testing activities in order to deliver on the team commitments.

Technical Debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. It often arises from taking shortcuts on analysis and design and skipping on unit tests and test automation, in order to deliver software at a faster pace. In Agile, where stories are prioritized according to Business Value, technical debt related stories can often end up at the end of the backlog, below the Release line. One way to avoid this pitfall is to include refactoring, unit testing, and test automation as part of the Definition of Done. Another is to encourage the Scrum teams to allocate a significant buffer for each sprint to burning through the Technical Debt.

Getting continuous feedback and having processes in place to act upon that feedback is critical to staying afloat and even on top of the Technical Debt. Monitoring KPIs such as Speed to Deployment vs. Bugs Missed, Defect Aging and Mean Time to Recover (MTTR), should provide a good indicator of how good the organization is getting with handling change and raise the alarm at the first sign of trouble.

In addition to evolving the tools and processes, QA leadership needs to evolve as well to keep up and thrive in the world of Continuous Testing and Delivery. The key to success in leading cross-functional teams is acquiring the T-shaped skill set, where the vertical bar represents the deep expertise in quality management and leadership, while the horizontal bar depicts the ability to collaborate across areas such as Development, UX Design, Product and Marketing, among others. In addition, strong technical background and innovative thinking can elevate the leader to the next level of thought leadership and help to create a culture of respect, trust, and innovation within the organization.

Charles Darwin once said, “It is not the strongest of the species that survive, nor the most intelligent, but the one most adaptable to change.” The agile model did not just change the process of delivering quality software, but the very definition of what software means. Our goal as Technology professionals is while adapting to the change not to give in or compromise on Quality. After all, the first underlying principle of the agile manifesto is “to satisfy the customer through early and continuous delivery of VALUABLE software.”

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.