So you want to change your [company, team, world]? Its a daunting task. You want them to do TDD, ATDD, using the flavor of the week toolset. You want to have business-driven, value-adding features. You want quality to be paramount. But for some reason you can’t get anyone on your team to follow you into the breach. I think we tend to lead people to a specific tool to encapsulate an idea. For example: I want to make better software? TDD! So, I should introduce my team to TDD? This is a backwards approach.
For a team to become a “highly functioning agile team” (a dubious thought in its own right), they first have to sit down and come up with a collective set of values. That everyone believes. If only one of the team members believes a certain thing, leave it off the list. Only come up with a list that everyone agrees on.
I would expect that some things will make the list out of guilt; someone says they love a certain thing and everyone else agrees to it because they feel obligated to. Try to avoid this. The most important part is that everyone MUST BELIEVE the things on the list. It can’t be half-hearted. I have met many a punk that claims to believe a certain set of values, preached and espoused them all the while just doing so because they were trying to fit in, or trying to impress some entity. True belief is the only way this will work long term.
Once you have a list, come up with [agreeable] actions to embody those beliefs. The important concern to keep in mind here is there are many ways to skin a cat. If everyone on the team wants to do pair programming because they all believe in better intra-team communication, great. But that is not the only solution.
These practices can’t be forced on people who do not want them. Make practices that tie back to the teams beliefs; that the team wants to do. If you can come up with a way to make better software without TDD, great! Use it. Don’t pigeonhole yourself to a single practice. Get buy-in. Remember that each of these practices needs to tie directly (and observationally) back to one of core beliefs that team shares. Make it clear how each practice ties back to one or more core team beliefs.
Its hard, but necessary, to take small steps. If you try and go zero to 25,000 mph in one-tenth of a second, you will not get where you wanted to go, and have some gooey floor mats (and no vehicle for that matter). As the team experiences more success and starts to discuss what’s working and what isn’t (which someday you may refer to as retrospectives), the team can add more and more tools and skills to support their core beliefs. After long enough, the team can re-evaluate those beliefs to see if they still apply, or a more explicit vision arises. If you start with nothing and go straight to advanced skills, you will fail and you will receive massive pushback.
PS: TDD is not the same as I wrote some stuff before I wrote some other stuff. TDD takes more skill than people give it credit for. If you try to implement it poorly your result will be useless and the prevailing belief will be that TDD sucks. So be careful...