Quality in Agile Development: Notes from Keep Austin Agile Conference

  March 25, 2014

 

I attended the Keep Austin Agile conference last Friday at the Renaissance Hotel in Austin, TX.  The conference was sold out, with 500 attendees. In fact, more than 100 people were said to be waiting on the guest list to get in.

Why all the excitement? It’s clear from listening to the presenters and the attendees at this show that most are already adhering to some form of Agile and want to continue to improve their processes. There is also an overarching belief that being Agile will directly and positively impact customer satisfaction and product quality.

But how, exactly?

First, Agile development is all about meeting exceeding customer needs. Product managers have always listened to their customers and developed roadmaps they believed would satisfy current customers while driving new adoption. Sticking to Agile disciplines simplifies this process by allowing development teams to break down user stories to their smallest elements and enabling them to change course as new market information is known. It also suggests that development teams release more frequently and initially promote a minimum viable product (MVP).

Second, and most important to me at the conference, was the attention attendees paid to product quality. If you’re releasing an MVP, how much attention do you pay to quality? One attendee  admitted that at her company, the MVP doesn’t even go through a code quality or QA process – it’s up to the customers to find the bugs and other deficiencies in the product.

This is exactly where a peer code review tool can truly benefit large teams that are following Agile processes. For small teams, having someone review your code can be as simple as shouting across the room at a colleague and telling him to look at your screen. But for larger teams, teams that are not co-located, and teams that truly want to ensure code quality (even if small and co-located) a peer code review tool is an essential part of Agile development for three essential reasons:

1.) First Line of Defense

Code review is a check of the quality of your product. For teams that are releasing without a structured QA process, code review is essential. Even those organizations that do have robust testing should review each other’s code to ensure high quality. Studies have shown that peer code review is one of the best ways to identify defects before your solution hits the market.

2.) Increased Knowledge Sharing

Tool-based code review is extremely fast – and yes, Agile.

Being Agile is all about bringing teams together and ensuring they can make quick changes as they learn timely market information. Code review facilitates that. When more people know more about the overall code base, they are better prepared to make changes to that code base. Peer code review forces that issue.

3.) Global Efficiency

Nothing can bring a distributed development team together in an Agile framework more efficiently than peer code review.

Some of the largest, most distributed development teams I know tell me that without using a tool for code review, their teams could not be truly Agile. Some even have developers in China writing code, submitting it to reviewers in the U.S. at night before they leave the office, and returning the next morning to find their code has already been reviewed. In this way, peer code review turns the disadvantage of not being co-located into a big advantage and actually saves time in their development process!

As I said, many are still trying to figure out how far down the Agile train they are – and how far they want to go. We all want speed. We all want agility. But we all want quality, too. What are ways your Agile teams are injecting quality into the development process?

See also:

 

[dfads params='groups=937&limit=1&orderby=random']