I begin this story by declaring up front that I am not an "Agilist" or process evangelist. I am the senior software development executive in a company responsible for delivering products to the marketplace. Like my peers across industries, I am fundamentally held accountable by my company for consistently delivering business results. Process and methodologies are important in delivering this value, but in the eyes of the company they are secondary to meeting the needs of the business.

Agile is a methodology that is seeing increasingly widespread adoption, and it is easy to understand why - especially if you consider the developer and user view-points. But, for the Test/QA professional an agile approach causes discomfort - In the ideal world they would have a ‘finished' product to verify against a finished specification. To be asked to validate a moving target against a changing backdrop is counterintuitive. It means that the use of technology and automation are much more difficult, and it requires a new approach to testing, in the same way that it does for the users and the developers.

As Agile software development practices mature and move into the mainstream, it is vital that organizations understand how Agile practices can help you deliver higher quality software. The Agile is a methodology for software development that promotes development iterations, open collaboration, and adaptability throughout the project life-cycle. Currently, the measures within many Agile projects focus on the successful delivery of software. We refer to these as process measures. Software is the end product and while these measures examine the progress through the delivery, there are other critical measures that need to be assessed. This collection of measurements we refer to as results measures. One critical measure that is often overlooked is called stability. That being said, the true measure of quality cannot be measured until after the project is done and the software is in production. I am not talking about improving the defect density.

Introducing Scrum can be fun, but can also be quite a challenge. There are numerous hurdles to overcome, new practices to master and problems to solve. In this article, we will present some of the mistakes we have seen made, or made ourselves when introducing Scrum at various companies. In this first article, we will discuss organizational learning, creating an environment of trust, and why Scrim should not be used as a quick fix.