Surefire Ways to Ensure Quality in Agile Projects

Surefire Ways to Ensure Quality in Agile Projects

The objective of any project is to successfully deliver a product within the given scope, budget, and timeline.

Quality is a central component as well. While working within these constraints, every project manager aims to meet, or even exceed, the client’s expectations.

To some, the agile method of project management looks like chaos, and spells out certain failure in this regard. Agile allows for continual pivoting and changing direction, even late in the game. And unlike waterfall, which methodically tests for quality right after development, agile has no designated quality management step.

But in fact, agile isn’t chaos at all.

When the method is closely followed, it enables a team to consistently deliver a top-notch product. Its system for creating user stories ensures accurate forecasting at the beginning of a project. And its ceremonies for review and reflection allow for constant improvement to the product and the team’s work patterns.

From planning, to process development, to review and reflection, let’s look at how to manage quality in agile, to ensure a team delivers excellence every single time.

Planning for an Agile Project

The simple principle that “you get out what you put in” certainly applies to agile projects. Smart, thorough planning is central to quality control. Here are things to keep in mind.

Create User Stories With Requirements

At the beginning of a project, having every stakeholder contribute to the requirements clarifies the project’s final objective.

A central first step to this process is developing a clear idea of the product’s end user. The product manager’s market and customer research provides valuable insight here.

Next, with the end user in mind, all stakeholders collectively write out user stories. It’s not necessary for the stakeholder to have technical knowledge in order to do this. A completed user story clarifies the end user, the requirement, what “done” looks like, and receives a point estimate to indicate its level of complexity. Matching the final output to all this information makes it possible to conduct quality assurance when the story is complete.

At this beginning stage, it’s key to gather a thorough and detailed list of requirements. You want all stakeholders to explain the features they want to see in the product. This information allows the product owner to map out the project and make good estimates.

If, rather, the requirements are vague, or not provided at all, it creates gaps of uncertainty. This forces the product owner to schedule buffers, which can really throw off a timeline. As the duration of this buffer is unknown, and could end up taking much longer than estimated, the team may have to work long hours and produce sloppy work in order to catch up.

Compromise on Time or Cost

Clarifying expectations at the beginning of a project means making some tradeoffs.

The “good cheap fast” triangle popular with project management provides a great framework for evaluating trade-offs. With this triangle, you pick two qualities, knowing that you won’t receive the third. For example, something can be good and cheap, but it won’t be fast. Or, something will be fast and good, but it won’t be cheap. Or, it will be cheap and fast, but it won’t be good.

When a team decides to prioritize quality, then it must either compromise on time or cost. If you don’t decide at the beginning to either extend the timeline or increase the budget, it spells out problems later. As the triangle dictates, you can’t have all three.

Use the MoSCoW Method

When a project has too many North Stars, or there’s simply a “let’s do this” mentality without much of a plan, the team flails and it creates dissension later on.

The MoSCoW Method of prioritization creates clarity around what a project sets out to do (and what it won’t do) from the very beginning. The method entails clarifying a project’s musts, shoulds, coulds and won’ts.

When all the stakeholders come together to discuss and establish these priorities, it allows a project to proceed fluidly. Rather than having to backtrack and sort through disagreements late in the game, the team is more likely to work diligently and deliver a quality product.

One thing to keep in mind with MoSCoW, however, is that the team shouldn’t be too fixated on the “musts” or “coulds.” The Agile Manifesto “welcomes changing requirements, even late in development.” This means that if it’s in the customer’s best interest to change course, the team does so.

Decompose User Stories

Quality control entails keeping batches of work small and manageable.

Rather than taking on an immense and complicated piece of work, agile is about completing a small task, then testing it, seeking feedback, and then planning more from there. Breaking work down allows for defects to be identified and fixed right away. If the task is too huge, then bugs aren’t noticed until much later, and at that point they may be too hard to fix.

When a project is particularly complex, determining how to break it down is a real challenge. Although user stories serve as a guide for iteration planning, many of them outline large tasks that would take several weeks to complete. And a single iteration usually lasts only two weeks.

One guideline for decomposing user stories is the acronym INVEST. This means the task must be independent, negotiable, valuable, estimable, small, and testable. When a task fulfills all of these criteria, it’s small enough to be performed with the due attention it needs.

Planning poker is a second method for estimating the complexity of tasks. In this activity, a team collectively assigns points to user stories, to help determine how many user stories to take on during one iteration. A team seeks to maintain a steady pace of work by completing the same number of story points from iteration to iteration.

Creating a backlog of decomposed user stories, all with points assigned to them, takes some time. Planning iterations can take up to 10% of a team’s overall production time. But doing this planning is central to quality control. It prevents overwork and allows the team to work at a continuous pace.

In sum, quality management in agile projects is first and foremost about having a good plan. A project is poised for success when it has good processes and systems in place, and has received input from all stakeholders.

Developing and Evaluating Processes

Nobody is perfect, including software developers. Every developer creates bugs or defects from time to time. Quality management entails having systems for identifying defects, and procedures to ensure defects are decreased or rooted out entirely. Here are three ways to do this.

1. Refine the Definition of Done

After a long day of completing code for a user story, it’s tempting to check the task off as “done” and move onto the next thing. However, at this point the code may still be full of defects, as it hasn’t gone through any testing.

In order to ensure quality, a team creates criteria for what it means for a user story to be code complete. This may include identifying and clarifying technical debt in the product backlog, and implementing processes for testing and reviewing increment before its release.

A thorough definition of done sometimes entails having a “done checklist.”

2. Identify Patterns in Defects

Reducing defects is part and parcel ensuring quality. In order to do this, it’s helpful for a team to categorize the types of defects it encounters.

One type of defect in software development is a build defect. This occurs during the development process. Another is a release defect. This defect has passed the user acceptance testing (UAT) and made it to market.

After a team has worked on several sprints together, it’s able to look at all its defects collectively and identify patterns. From there, it can create a plan to reduce them.

For example, high incidence of build defects indicates the team needs to focus on improving the development process. A pattern of release defects indicates a need to improve its UAT.

A sprint retrospective is the ideal time for a team to discuss any patterns in defects, and work to collaboratively improve processes and systems.

3. Onboard New Team Members

When a new team member is hired, it instigates the “norming storming” cycle, which spells out lag in product development.

A proper onboarding system shortens this cycle, and ensures the new member contributes meaningfully to the product development right away. Effective onboarding entails education about company culture and assigning the new hire a mentor and someone to go to for support.

When someone comes onto the project mid-way, he or she can be brought up to speed by watching videos of sprint review meetings. These communicate the increment that was previously developed, the impediments discussed and client feedback, all which give the new hire a good understanding of where the project is currently at.

In sum, processes are like the glue that holds a team together and gives it the structure to successfully bring a project over the finish line. Regardless of the talent and skill level of a team, quality isn’t assured without good processes.

When systemic defects or impediments are identified, the processes can be updated accordingly.

Review and Reflection

The agile methodology incorporates constant check-ups, communication and reflection. The Agile Manifesto says that “business people and developers must work together daily throughout the project.” At the daily stand up, the team assesses how the iteration is proceeding, and identifies both progress and impediments.

The scrum framework, particularly, allows for reflection periods in order to evaluate work and identify ways to improve processes. Let’s look at how to make the most of these in order to ensure a quality deliverable.

Hold Sprint Retrospectives

In scrum, the team gathers for a sprint retrospective at the completion of a sprint. During this ceremony, it analyzes how everyone worked together, and how the team was (or wasn’t) supported by the organization.

The goal of the retrospective is to identify impediments and specific ways to improve the process for the next sprint. The sprint retrospective is the ceremony most scrum teams skip. However, consistently practicing this ceremony helps a team handle defects and improve quality.

A retrospective allows a team to address systemic issues and defects as they occur, and prevents a scenario where a team needs to dedicate an entire sprint to fixing all the defects in the previous weeks’ work.

Dig During Retrospectives

An effective retrospective doesn’t simply identify problems and impediments. It also seeks to uncover root causes. When an impediment is identified, it’s helpful if a scrum team asks a series of “why” questions.

Let’s say a team launches a messaging service, and within minutes it crashes. An immediate explanation would attribute the failure to poor testing.

A good retrospective goes deeper, however. It asks why there wasn’t good testing: Is it because the team didn’t understand how to write tests? Or there wasn’t enough time? The root cause of the failure may have to do with training, staffing, or time management issues.

When a team asks “why” questions, it’s able to take steps to resolve root causes, not simply surface problems. This sort of digging ensures quality in the final deliverable, and it prevents the same snafus from happening over and over again.

Listen to Feedback at the Sprint Review

At the end of a sprint, the team meets for a sprint review. They look over what it has accomplished and any completed product, called increment, is shipped to the end user for feedback.

Listening to this feedback is central to the agile process. It allows a team to evaluate its work up to that point, and determine if it needs to pivot in order to create a quality deliverable.

In this respect, agile differs markedly from waterfall. Waterfall plans its objective goal from the very beginning, but agile allows for flexibility. Oftentimes, this flexibility is the necessary ingredient to delivering a quality final product that the end user likes and enjoys using.

Run a Hardening Sprint

At times, an agile team may have a build-up of defects and technical debt in the product backlog. A hardening sprint is helpful for cleaning up messes and clearing up bottlenecks.

It’s good to be transparent in the product backlog about technical debt. This lets the stakeholders understand what is going on, and makes it clear if the hardening sprint is necessary.

The hardening sprint is generally used as a last resort, but it is a helpful process for continually maintaining high quality.

In sum, reflecting is central to quality management in agile. By continually taking the time to reflect, and improve processes, and listen to feedback, a team ensures that it’s on track to producing high quality product.