These days, when I hear a quality assurance engineer isn’t involved in the development process until testing, I admit to being surprised, especially as more and more companies embrace Agile. The former Waterfall approach, with testing performed at the end of the development cycle, is becoming obsolete. However, old habits can die hard.
Organizations adopting an Agile methodology, especially public sector ones, may still perform testing at the end of a sprint rather than throughout the sprint. I refer to this as “Waterfall within Agile.” The problem is that when both methodologies are in use, it can derail a project.
Challenges in the transition
It’s true that the adoption of the Agile methodology has the potential to be a slow process, and notably so in the public sector. “The challenges in implementing Agile were, and still are, significant,” Agile Government Leadership (AGL), a consultancy company, notes in “Case Study: Agile Government and the State of Maine.”
“Government has an inherent bureaucratic nature, which naturally leans to tailoring projects around a waterfall development methodology,” the report states. “The nature of Public Sector is to consider and be deliberate in decision making. Traditionally, there has been value in not being able to change your mind. Yet this can, and has, resulted in multi-million dollar project failures.”
“Waterfall within Agile” can be an unintended and non optimal outcome on the transition to Agile. Similar to pure Waterfall, it can cause the following issues:
- Issue: Questions about business requirements arise during testing at the end of the sprint.
Problem: The team doesn’t have the proper amount of time to get responses, putting sprint deliverables at risk. - Issue: Developers work on multiple stories at the same time.
Problem: QA must be performed for multiple stories all at once at the end of the sprint. - Issue: Testing tasks aren’t closed because stories can’t be considered complete.
Problem: Stories must be carried over to the next sprint.
All of the above issues have detrimental effects on meeting deadlines and finalizing deliverables. As a result, Waterfall within Agile projects do not reap the benefits of the pure Agile approach.
idalink case study
In my experience with the Agile implementation for idalink, a benefits portal for the State of Idaho’s Department of Health and Welfare (DHW), the Agile adoption met a number of challenges before it hit its stride.
Luckily, DHW management was constantly looking at how Agile could best be implemented. They were understanding of the challenges and roadblocks and sought ways to make improvements. Working with AgileX, an Agile consultant firm now owned by Accenture, DHW management helped implement strategies to avoid such things as Waterfall within Agile.
We learned the hard way that a larger team isn’t necessarily better. Smaller groups of developers and QA would groom, develop, and test backlogs, but we weren’t operating as a cohesive unit. Developers tended to collaborate separately from QA engineers. These old habits created a wall between the two disciplines and contributed to the “Waterfall within Agile” issues defined above.
Agile consultants worked with business leadership to reduce the overall team by a significant number and to determine the most effective team makeup. We designated a subject matter expert/product owner to lead a small team of six. This allowed four developers with strong technical skills and experienced QA engineers to work together on all stories. It has turned out to be the best formula for the project, and keeps QA involved throughout the sprint.
Strategies for avoiding Waterfall within Agile
A finely-tuned team is not established overnight. We found old habits continued to resurface. Even though we groomed stories together, developers would revert to working on stories by themselves. QA engineers would write test cases in isolation and execute them. We attempted to collaborate when questions or issues arose, but there were certainly sprints when the burndown chart resembled a waterfall. By addressing this in retrospectives, we realized we weren’t following some of the main tenants of Agile.
We implemented the following strategies to get back on track:
- Swarming (when everyone on the team works on the same story, which promotes knowledge sharing and on-the-fly code reviews)
- Work in progress limits (which meant we were able to fully complete backlogs as a team before moving on to the next BLI)
- Whiteboard sessions (these team meetings with visual whiteboards ensured everyone understood requirements and how they would be implemented)
- Test case sharing (defining the test variables and conditions allowed the team to make sure requirements were implemented correctly and see where functionality in other areas of the application might be affected)
Trusting the Agile process
Breaking down old habits and perceptions can take some time. As the team evolves, each person is able to share the perspective of their traditional role. Thus the rest of the team learns to recognize the importance of their colleague’s expertise and incorporate it into their thinking.
Even though the Product Owner and some developers have changed, the Agile approach has become so well adopted by all that we no longer need Agile coaches.
As long as we adhere to these basic Agile tenants, we are able to stay on track.
- Plan appropriately: Ensure that stories are small, discrete, and can be managed by all or most of the team.
- Work on stories in priority order: Rather than have multiple developers working on multiple stories at the same time, ensure that they are focused on only one or two stories at a time in priority order. As testing on a story takes place, developers support the test effort while looking forward to the next story.
- Remember that in Agile, team members can wear different hats: QA is the responsibility of the whole team and should be incorporated during all aspects of the backlog item.
Conclusion
No matter where an organization or agency is in the transition to Agile, leaving QA to the end impacts sprint deliverables, velocity, and creates friction between team members. It’s important that project teams adhere to the principles of Agile throughout the sprint. Then they can respond accordingly when they see a project take on the characteristics of Waterfall within Agile.
No one wants a product delivered with buggy code, missed requirements, and behind schedule. Instead, when QA is part of the team from the start you are more likely to get:
- A fully vetted quality product
- Functionality that meets business needs
- A product delivered on time, on budget
- A well-rounded team that has full understanding and ownership of their deliverables
Contact us to find out how our QA team can help make your project a success.
Diane Bienkowski, a.k.a. the Queen of QA, as she’s known around the office, has practiced QA for longer than seems possible considering her youthful appearance. She has worked in financial services, health care, and the public sector with the State of Idaho’s Department of Health and Welfare.
