Don't Fire QA - Embed QA in to Agile teams

Mike Gualtieri recently wrote a post about how 1 financial data company was able to improve software quality by firing their QA team and making developers responsible for testing the software. This is a good concept - have the team of engineers responsible for creating the software also be responsible for proving the software works. I agree that you should break down the barrier between a development team and a QA team. I disagree that you should fire your testers. You should Embed them in to Agile teams.

I met with a client today who described doing weekly releases to a very high volume online advertising system. This system has hundreds of servers around the globe and is directly revenue generating software with complex algorithms. His approach was not to fire the QA but to embed them in to the development scrum teams to help the developers make even better software.

This is one of the basic tenets of typical Agile software development approaches. To quote Janet Gregory, Agile teams have "Blurred Lines Between Roles":

• Agile developers are "test infected"
• Agile testers and programmers collaborate
• Agile testers and customers collaborate
• "Whole Team" responsibility for testing
• Everyone understands the business

When you follow these approaches, you get Unit tests from your developers. You get acceptance tests written for user stories BEFORE the code is written. You get developers who try to prove their code works, not who just try the happy path and throw the code over the wall to QA and wait to see what bugs get reported back.

When you have developers who are responsible for executing regression tests, you get automated unit and regression tests to validate the software in every build. And when you have developers who are responsible for successfully deploying the software to production they think about how to automate the deployment so it works every time. This is all good!

But you still need people who are trained to think about testing, requirements, and user story completeness, and who are used to looking for corner cases, and thinking like a user, and who have seen bad data, funny encodings, and the hundred other oddities that a skilled tester can find in software.

This is why it's better to embed the QA testers in to the scrum teams. The TEAM is responsible for the software quality. The 1 or 2 engineers on the team with a QA background go about ensuring quality differently - they work with the users and customers more to ensure the team really understands how the system is going to be used. They build automated tests for parts of the system that are not easy to automate with unit tests. They double check the consistency of the look & feel. They run stress tests. They manage sample data. They ensure that 2 user stories do not conflict with each other. They do all the things that a developer focused on a single user story might miss or not realize was important, because after all the developer's code passed the unit test and passed the acceptance tests.

If you want great software, you need more than just coders. You need testers - but you need Agile testers who are part of the software creation process, not a separate team given an impossible task of "finding all the bugs" in code casually written by the coders. Don't fire, EMBED QA!

Iterative Development Key for New Product Development

There is a lot of discussion about Agile vs. Plan Driven software development methodologies - usually driven by advocates of one or the other. Certainly, it's a more complex topic and there is a wide spectrum of extremely structured, plan-driven approaches to extremely agile, change embracing approaches. One well thought-out and nuanced explanation with advice for choosing where on the continuum to try to be can be found here.

Two concepts are fairly easy to accept and understand - one is that when you need to coordinate many different parties a more planned approach with more formal communication between the parties is essential. This comes in to play when coordinating marketing campaigns, customer roll-outs, contracts with vendors, and corporate funding approval processes. In all of these cases you need to have an idea of how long an effort will take and how much it will cost - and all of the stakeholders involved need to be formally updated to changes in the overall timeline or cost . This can form the basis of the overall planned Program at a high level.

The second is that at a lower level of detail, and especially with new product development, it is impossible to formally plan the software development with any degree of accuracy regarding how long each feature will take or whether every scalability and performance metric will be achieved by the first, second, or third attempt. Additionally, the new product development implementation process is really a R&D process, not a defined engineering approach. You need to explore whether customers can understand the new product, whether the new UI makes sense, whether the most anticipated features are actually used, and on and on. As part of your new product conceptualization, you need to prototyp, build, and let customers work with the software to learn what is really needed in the product. Josh Green, the CEO of Panjiva, explained it well during his presentation at the Information Industry Summit this week:

When we showed Panjiva to our first customers, we expected them to be blown away - we were giving them more data, more easily to use than they ever had before. But they kept asking for more data or asking for the data to be shown differently. After a while I realized that my customers were TEACHING US HOW THE PRODUCT SHOULD REALY WORK!

This is the essential point about truly new product development - it is an exploration. No one can completely specify in advance how the product should be implemented. Users will teach you how to make the software better. But users can only teach you when they react to something that you put in front of them. Iterative development, and especially early prototyping and mock-ups are key to enabling this customer feedback loop. It is imperative to learn from your customers and deliver the next version quickly so that they continue to see the improvements and continue to help you make your product better.

At the same time, you probably need a Program level plan - how much funding do you have? How many iterations can you afford? What conferences or industry events make sense to demo your software at?

So you see, it's not always either Planned or Agile, it's often "both."