Best concrete "how-to manual" on MANAGING Test Driven and/or Agile development?

Question

Obligatory up-front clarification: I have a great boss. Very smart guy. Respectful towards all. Dude is awesome. Seriously.

Now for my question:

I am looking for an easily digestible book to possibly present to my boss/team.

---

Background info: More and more of our meetings at work involve my boss/team pondering how to implement more "best practices" around here. ("Here" = a very small application development shop. 4 developers)

The following things are items that my whole team agrees that we need:

• Nightly builds
• Decomposing "bugs" in our bug-tracker into smaller, more-specific items
• Automated testing

The problem we face is how to get started.

I believe that if my shop could simply choose a clear and specific plan or set of rules, then everything else would fall into place. Right now we are stuck in discussions of fuzzy, feel-good ideas and nice-sounding buzzwords.

Please recommend to me your favorite book (or online resource) that contains clear, discrete, sequential steps for implementing a management scheme for guiding a TDD or Agile team/shop.

I realize that there are other paradigms besides TDD and Agile that would also address these concerns, but my own self-interests and biases point toward TDD and Agile so I would love to harness my team's desire for change and "nudge" it in that direction. Or feel free to slap me down if you vehemently disagree with my sentiments! I will take no offense. :)

As others have stated, I think these questions are answered best when respondents list only one book recommendation per answer.

---

Thank you all.

Answer 1

For your needs I recommend Test Driven Development: By Example (Kent Beck). It is clearly-written, more practical than theoretical, and prescribes time-tested recipes to adopt an agile, test-driven approach.

Answer 2

It's not really a step-by-step book, but full of great advices and easy to digest: Practices of an Agile Developer. And if you want to have in house TDD training, I recommend netobjectives. I had their TDD course ones and it really opened my eyes.

Answer 3

I suggest that you start with what you agree on: Nightly Builds and Automated tests. Nightly builds is a no-brainer. For Automated tests I would start with:

• Each commit with new functionality should have at least one automated test
• Each commit that fixes a bug should have at least one automated test that fails without the fix and succeeds with the fix

If you do this, you will start to gain experience. With this experience it will be much easier to understand all the good advice that the literature has.

There is a lot of good books on good practises, but you have to figure out what works for your team.

Answer 4

my favorite is Planning Extreme Programming

EDIT: it provides a complete replacement for traditional project management geared towards an XP/Agile team

the danger is, adopting modern development methods and then strangling them with archaic project-management and administration practices!

Answer 5

Sadly, even the most clear and specific plan can turn out to be disputable.

I'll tell you what works. Starting TDD immediately. It has boundaries. It's relatively easy. You'll still have a million questions.

You are free to say, "But what about nightly builds?" "What about using the bug tracker?"

A lot of pondering can mean one of two things.

First, it can mean that someone is muddying the waters with "concerns" and "questions". Sometimes this is really displeasure at changing, voiced as "concerns". Sometimes this is really crushed egos ("I thought I was pretty sharp, now someone is saying I must have improvements imposed on me.")

Second, it can mean that this is dauntingly large. Consequently, don't look at this as "Many New Best Practices". Look at this as just a few incremental improvements. You're not changing yourselves fundamentally (well, that could happen, but don't start out with that as your plan.)

My experience is that you can only do one new thing at a time. Do TDD until it's boring. Then do something else. Often nightly builds become obvious after you have a robust test suite. Then when that's boring, do some other small, incremental process improvement.

One thing at a time. Baby steps. Avoid throwing out babies with bath-water. All you want is to be a little better next month than you are this month.

If there are concerns on adopting one small incremental improvement, find the root cause. Who's ego is bruised? Who's worried about change?

Answer 6

To throw another Pragmatic Programmers title in the mix: Ship It!

Great book - take a look, might suit your needs with management.

Answer 7

You can print him Scrum and XP from the Trenches by Henrik Kniberg, It's more focusing on agile development process that on TDD, but it's an easy and quick read.

Answer 8

Agile methods are not really methods...

There are more a spirit. The main is a focus on :

• communication

• reactivity to changes

• customers orientation

This can be achieved in lot of ways, and it's more important to find your way to do it. If you want an example of what this spirit can be, you can read the free 37signals' online book, Getting Real.

But there are some steps you can start with

They are no big rules you must enforce, but you can try the following and see how it goes with you team :

• Quick stands up meetings. 5-15 minutes daily meeting where everybody stays up on his feet and explain what he has accomplished, what need to be done and what can prevent him from doing it. Keep it under 15 minutes, with the minimum number of people.

• Set simple goals for short term deadlines instead of big goals in weeks.

• Build small team (3 persons) and divide the work between them. Put them in the same room and ensure they have at least half a day to work without ANY interruption.

• Set many little regular review with your customer. Don't write specs. Sketch, design, prototype, show to the customer, fix/adapt/change then build. Then do it again.

• Testing, versioning, bug tracking are tools, not methods. No one cares how you do it and with what software are long as you do it. They are not the issue.