Organizing QAs in Agile software projects
Since the inception of the software development domain, we have been following traditional project management methodologies, mostly Waterfall, V-model. However, over time, companies have realized its downside and as time goes they are adopting Agile methodologies in their development workflows.
However, as most of these project people have been through that traditional project management era, they are still stuck at those notions which halt us from getting into the full potential of agile development. Software Testers, QAs are those unsung heroes, who in most cases unaware of their true engagement in Agile methodologies due to the above said dilemma.
We will here see the problems with QA involvement in modern-day software development projects and will dive into some thoughts to overcome the same.
Problem Statement
In most cases, you will see companies have adopted Agile Methodology for one of the following reasons:
- A significant delay in development or a critical bug has cost a lot to the company and now they are in need to redesign its development workflow to eliminate such risks in the future.
- Other peer companies working in the same domain adopting Agile Methodology, so they should too.
- Agile is the new trendsetter in the market. It can upscale the company’s brand image.
- Old management techniques are not sufficient to handle the new generation workforce.
Companies bring up people on board to revamp the workflow, reshuffle the teams in order to harness the power of the Agile. The people that the company brings in can be excel in their position, but they may not be familiar enough with the company’s existing workflows. They try to implement things as they have been taught or may be applied to a different place. Later we end up migrating the project to Agile, manager celebrates, Director gives kudos, the team gets excited. After a few months or so, problems start arising, tech debts start increasing, standup gets longer, co-ordination reduces, quality of shippable product decreases. Now, this end part is where QA comes into the picture. Let us see why is that?
Fast-track adoption of Agile methodologies
We must understand migrating from traditional to Agile project methodologies is not an overnight event, rather a well planned long project itself. The more people involved in the project, the more time it may need to migrate.
Adopting Agile fast does not give time to people in that project to adopt it themselves. Whereas, agile strongly flows around people, not the product. We must consider migration as a separate project itself, not as an event. For real-time or SaaS projects, this could be a challenge as they cannot have the luxury for a lean time. Hence in such cases, separate measures shall be taken so that the existing project goes on till the time team picks up Agile well and good.
Not enough modularization
In traditional development workflows, the project used to be split up based on functions, not features. While transitioning to Agile development, we miss out on this big thing. We move our project to agile, but we tend to keep going with the pre-existing skeleton of teams and products. This isolation of modules fails to adopt a fast shippable product iteration, that what Agile principle stands for.
Sense of ownership
The agile manifesto says to give away control to people who are actually adding values to develop the end product. Giving away the controls boost enthusiasm among the team, bring confidence on own work, and also people start taking end results as their responsibility than just a tick mark on their day to day life.
Lack of engagement
Traditional development models did not give importance to QAs in their project planning and grooming sessions. Few teams may not have such a team in place even. Management used to plan everything themselves. This lack of engagement drops the morality among QAs in the team. Additionally, management sometimes missed out points that should have been considered while planning, that may have come from the QA team. This could have saved significant delays or re-work.
Solution to explore
Now we see the challenges that are out there which is blocking us to gain the full potential of Agile methodologies even though in the paper we have adopted it. Let us dive in and see what are things we may want to tweak a bit that could significantly improve the process and the team.
People over products, always
Build a development process that flows around people of the team, who are actually adding value to the end result. If we take care of the people, those people will take care of our product. Give them all the resources they need. Put time to empower the team, encourage them, let them decide the correct way of developing the feature. Give them what to do and let them decide how to do it. If your team is lacking in knowledge or awareness of proper Agile principles, you must consider hiring an Agile coach, whereas a Scrum Master stays the primary contributor to the Agile workflow.
Break it to make it (better)
Break down those isolated modules and teams that you have inherited while migrating to Agile. Break them to the most granular level (individuals) and then build up teams or sub-teams based on end product they are delivering. A shippable product could have 3 primary features — build 3 teams working closely among themselves to deliver the 3 features. It reduces the risk of high dependency among teams and also fastens the development time as co-ordination increases.
Pass on the ownership
Give away the control to the people who are actually adding value to the product. Give the QA full authority to conduct the testing, prepare the test plans, brainstorm the use-cases with the product owner, fix the bugs with developers. Include them in all agile events. Consider their experiences as a major input in the planning and grooming meetings. This could help us to reduce unforeseen bugs and errors at an early stage. Ask for their sign-off before shipping any feature to the customer.
Don't let settle
One of the major problems with traditional development models was, over time people tend to go low enthusiasm due to repetitive or monotonous work. Agile gives us the feature to play within every iteration of it. If two teams are building parts of shippable products after a few sprints let the QA shuffle in between those teams. It will enhance their knowledge of the product, which will increase the confidence in the quality of the shippable product. And as this shuffle takes place every time, people generally won't get time to feel monotonous for a long.
Conclusion
The above discussion not only covers QA but every individual working inside the development team under Agile development projects. Migrating from traditional to modern project management workflows enables the fast product to market strategy that is necessary to survive in today's competitive market. Having teams aware and educated about Agile manifesto is now a must-have.
Hope this helps!
