Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Baking Test Driven Development into Agile Software Development : Page 2

Learn how to introduce Test Driven Development (TDD) to your Agile software development team and then help them continuously improve their TDD practice.


advertisement

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



Internal

External

Pairing (Senior Dev with Junior Dev)

TDD Coaching Expert

Code Katas

Agile Immersion Class (see Figure 1)

Brown Bag Presentations

Code Camps

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).



Click here for larger image

Figure 1. Agile immersion Training

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!



Eric Landes is a Project Manager/Project Lead for a large corporate IT department, specializing in coaching Agile teams. He has more than four years of experience using Agile/Lean techniques to bring customer value and a team focus to projects.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap