Agile processes can help teams to plan, and make the process transparent to management. Planning sessions, release plans, and all other techniques that help Agile teams keep their work transparent are helpful. Those techniques should help all development teams deliver software at higher quality with more predictable timing. Teams that want to be highly productive need to focus on their engineering techniques as well.
This article focuses on one of the Extreme Programming (XP) techniques that help teams become highly productive, Test Driven Development (TDD). It explains how to introduce the practice to the team and help them to continuously improve with this practice.
What "Highly Productive" Means
Highly productive teams or hyper productive teams have been described in Scrum as "...teams that have achieved a state of ownership, commitment and collaboration that allows them to be far more productive in creating 'product value' on a regular basis."
For our purposes, hyper productive teams perform at a significantly higher level than they previously did. I categorize this improvement as 2 – 3 times better than previously measured productivity. A team that is completing an average of 7 stories per iteration or release cycle would achieve 14 – 21 stories per iteration or release cycle. This velocity is achieved without impact to quality. These should be high quality releases.
TDD can help teams increase their quality, especially in future releases. TDD provides a safety net for applications, allowing quicker regression testing for changes to the application. This desirable trait of craftsmanship needs to be introduced to those teams unfamiliar with it. The following steps are intended as guidance to help team leaders, project managers, software development managers and others to introduce and bake TDD into their team's process.
Defining TDD in Agile Software Development
The software engineering practice most associated with Agile and especially XP is Test Driven Development (TDD). Kent Beck's book Test Driven Development by Example is the original blueprint of how teams can adopt this practice. The intent of Test Driven Development is for the test to drive development! That sounds obvious, but in practice this means that developers develop code by writing the tests first. That first test fails, and the developer refactors the test until it passes. This helps the team develop by designing the code against customers' requirements.
It is essential that the person introducing this practice understands the fundamentals. It is helpful if they are passionate about craftsmanship. This practice does not mean that the team simply adds unit tests around their code. Good TDD forces coders to consider design as they are coding. It can also bring QA into the process earlier than your team might normally interact with QA.
This can happen by using pair programming techniques to help disperse knowledge. One pairing method is to pair a developer with QA. This kind of pairing can bring a higher quality focus depending on the individuals involved. Another way to bring QA folks into the process earlier involves having QA and the developer validate the unit tests against the stories acceptance criteria. This can bring up conversations with QA about the acceptance criteria.