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.

Techniques to Start Various Agile Team Types with TDD

To help a team start the practice of Test Driven Development, some training is necessary. There are a variety of types of training available for your team to understand TDD. Choose your training type based on the composition of your team.

Table 1. Different Training Types That Can Be Utilized for TDD

Table 1 represents a mix of training options that your team can utilize. Keep adding options to your bag of tricks to help the team continue to become a proficient. Below are a couple of different scenarios for teams, and how you can use the above training to form a continuous training strategy for your team. While this training may not always focus on TDD, it should focus on good craftsmanship practices like TDD.

Mix of Experienced and Junior Developers

A mix of experienced and junior members can introduce TDD via internal training, using a combination of training programs and pair programming. If the team is all new to TDD, an Agile Immersion class that showcases TDD practices is a great jump starter for your team (see Figure 1).

To all be on the same page, the team initially attends TDD training. Once that training is over, the team is ready to start coding using TDD. The only way to get better at TDD is to use it! Using pair programming should help reinforce concepts learned at training.

Remember that initial training is not the end of TDD training for the team; it’s just the start. How can your department provide training to the team — training that helps keep the team’s TDD knives sharp without dramatically increasing your training budget?

Look for team members who continue learning both inside and outside of work and encourage those who don’t to do so. Encourage reading books about TDD for retrospectives, going over a chapter at each retro (this does increase the time of retrospectives). Outside of work there are software craftsmanship user groups, coding camps and other community-driven ventures. These are free or low-cost events that are driven by passionate community members. Those team members who respond well and are passionate about learning in these different ways are the members to help drive the team’s TDD adoption.

In turn, these team members can help implement internal TDD practice sessions for team members. For instance, have one or two of these members lead code katas for the team on a daily basis. Management needs to agree this is important, because something like a code kata can take a half hour a day out of the team’s time. Sell the benefit of the team practicing their craft and becoming better professionals as the main benefit.

Also, encourage brown bag lunches that are attended voluntarily by team members. Those team members with a passion for TDD can give a talk about certain aspects of the practice. For instance, they could do a round robin discussion on how they use mock frameworks. If the organization is so inclined, springing for lunch occasionally for these is a good motivator as well.

Most Team Members Are Junior Level

For teams that are just spinning up, there may be occasion when the majority of team members are from the junior level. Even with one or two senior team members, this can be difficult to introduce. While starting with training is recommended as above, there is considerably more effort needed after that training.

A coach for the team is needed to ensure that the team starts utilizing those practices in their iterations. This coach can be the team’s software development manager (if he or she is available) or someone outside the team. But the coach needs to be integrated with the team for an extended period of time. While this may vary by team, it could be anywhere from 6 weeks to 6 months.

If the coach is the team’s development manager, this is not a huge concern. That manager should be working with the team and in the same open space. If the team’s development manager is experienced with TDD, this should work out splendidly.

If this is not the case, perhaps the organization can move an experienced manager with TDD skills from an existing team to the new team. That team’s manager or lead could learn TDD from the experienced team, while the experienced manager can coach the new team in TDD. If your organization does not have this skill set, consider hiring a coach on a temporary basis.

If the organization contracts the coaching out to an external party, have some rules about transferring knowledge. The team’s manager should shadow the coach as much as possible, taking notes on techniques. Make a goal to identify two team members who are passionate about this practice who can lead the team once the coach is gone. Then develop a plan to ease these members into that coaching role while the coach is there. At some point during this period, it should be obvious that the team is ready to use TDD without external coaching.

Ensuring Continuity of TDD in Agile Software Development Team

How can you know that your team has embraced TDD? The real proof is sitting down with them as they pair and watching their development process. But metrics can be utilized as well.

Make sure to run code coverage metrics regularly. While this alone does not tell the team about quality and actual use of TDD, it can keep the team honest about how much unit testing is going on. Regular code reviews can also help a team recognize their practices. TDD should drive good code design, and lapses can come out in the reviews. More importantly, developers discussing their craft, and the code base design should drive more understanding among team members.

The best sign of your team’s buy-in to TDD and other craftsmanship practices are their forays into new books and communities. If members of your team are actively going to code retreats or reading new books to increase understanding, these are signs of an increasingly mature team. Ultimately, the productivity of the team should show this progress over time as well.

When your team reaches this point, they are ready to look at new practices, because the Agile journey is all about learning!