10 Ways to Build Quality into Agile Software Development

How to move fast, be flexible, and maintain high quality while building a digital experience.


Many newcomers to agile software development methods are impressed, if not terrified, at the frequency of changes made to an emerging product’s requirements and codebase.  Digital leaders understand that agile processes can improve adaptability and time-to-market.  But, with so many changes happening so fast, how can a team possibly maintain high quality?  In this blog post, I’ll describe 10 practices used by successful delivery teams to overcome this challenge.   


1) Clarify business goals and metrics up front

Yes, agile does require planning.  Before design or development begins, the client and delivery team must identify the business drivers and goals for the project.  The team should also agree upon metrics that will be used to evaluate these business goals.  All further quality assurance and control efforts should directly relate back to these goals and metrics.  Without this foundation, “quality” is meaningless jargon.


2) Draft the Drupal content model and application architecture before development begins

Using agile methods doesn’t mean that the team has to create code on day one.  Tracing individual pull requests of code back to business goals and metrics is much more successful when the team can reference an intermediate step.  I’ve found the Drupal content model and application architecture to provide the most value for this intermediate step.  As development proceeds, these decisions can be adjusted, but starting with the end in mind prevents confusion and rework.


3) Start sprints with fully groomed user stories

In a sprint-based process, the delivery team should use the Sprint Planning ceremony to verify that for each user story planned for the sprint:

  • The product owner has agreed to the acceptance criteria
  • The development team has drafted and estimated the implementation approach

The acceptance criteria sets the quality standard for the user story and will serve as the evaluation criteria for testing the user story.  Without the acceptance criteria detail finalized, the team may draft and estimate an implementation approach that solves the wrong problem.  


4) Enforce coding standards in local developer environments

Delivery teams should use tools, such as the open source BLT tool, to enforce coding standards in developers’ local environments.  This practice catches small errors before they are ever submitted for integration.  It also creates code consistency that leads to faster code reviews, more efficient debugging and (if applicable) easier re-usability in the Drupal community.  


5) Review code, automated test, and manual testing steps before integrating

Every Drupal delivery team should include a Drupal expert responsible for architecting the technical solution.  One way they do this is with a manual review of the feature code, automated test code, and manual testing steps produced for each user story.  This review happens on an isolated code branch before anything is integrated with the main codebase.  In addition to ensuring that the work meets the established standards, the reviewer will consider the code’s purpose, scope, implementation approach, style, security, performance, test coverage approach, configuration management, and documentation.


6) Automate code integration, testing and deployment

Nearly every agile practitioner will say that automation is key to success, so I’ll say it too.  In an agile process, automation is key to successful quality control.  Modern web development requires this skill set and practice, yet many enterprise IT departments lag far behind the vanguard.  Successful Drupal delivery teams accomplish this through tools like Acquia Cloud, BLT, and Lightning.


7) Demonstrate completed user stories to the product owner

At the heart of the agile scrum methodology is the Sprint Review ceremony, which includes a demo to the product owner.  This demo should be conducted in the same hosting environment where product owner testing will occur.  This ensures that any environmental issues are resolved before the demo, and don’t change before product owners start testing on their own.  


8) Require product owners to test individual user stories

Most product owners will not feel comfortable approving a user story based only on the brief demonstration provided in the Sprint Review ceremony.  The delivery team should provide client product owners with several days after the sprint to review and triage the delivered product increment.  This practice ensures that the product owner has sufficient time to inspect and respond to what was delivered, while the team starts developing the next sprint of user stories in parallel.


9) Conduct independent security and performance audits

When approaching a launch, the delivery team should bring independent security and performance experts into the project to evaluate the application’s fitness for the production demands it will face.  Drupal includes many security and scalability features out-of-the-box, but as custom code, configuration, and content is introduced into the project, the overall application needs to be audited to ensure conformity with quality standards.


10) Follow prescribed checklists for pre-launch and launch activities

To avoid overlooking any necessary step during an intense launch phase, successful teams draft in advance, and then follow strict checklists for pre-launch and launch activities.  No matter how many sites our teams have launched, everyone is human and susceptible to mistakes.  The process of collaboratively creating and following checklists during this critical phase protects against human error so that launch day is always a success.


In my experience, agile delivery teams using the practices described above are much more likely to have successful projects and satisfied clients.  I believe that quality assurance and control processes baked into the delivery methodology are the basis of agile success.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s