Currently I’m working on a team of 8 developers and have been practicing Agile for just under 2 years now. I read about it and tried a couple time before this 2 year span, but didn’t realize how wrong I was approaching it. Scott Bellware has been posting about how Agile development does not have the answers and this line:
“The essence of TDD is a suspension of our belief that we know what we’re doing, and a submission to a structured process of exploration and elaboration of ideas.”
“I think that the difference between a good developer and an excellent developer is the excellent developer’s willingness to not know, an openness to explore, and faith in skills that guide solutions to good ends even when the end is not known at the outset.”
The team I’m on practices an Extreme Programming / Scrum process and my
manager Agile coach, AgileJoe, makes a good point when he states that an XP value he believes should be in the core values is Humility. The current list is awesome, but humility allows for the items that Scott mentions in his post.
When I tried to get a different department in the same company to change it’s process to Agile, I met great resistance (as expected). Change = fear. The greatest fear was from the programmers on the team that specialized in one section of the software and were afraid of either learning a new portion or having other developers critique their code. One of the core values of Extreme Programming is courage and it was hard getting that across. Scott speaks the truth when he states:
“Agile will show you more problems than you ever thought you had before you start to see some progress against these problems.”
Much courage is needed to take that step. If you are blessed to have the process started by an Agile coach, like the team I’m currently on (they had Michael Feathers from Object Mentor pay a visit), then the “sparking” of the process may be a little easier than a complete agile newbie (myself on the other team) trying to get it going.
I don’t claim to be a excellent developer or an agile master, but in the environment I’m working in we strive to minimize any hero programmers and focus on code ownership amongst the group. By doing this you allow for everyone to grok the entire domain.
To expand on his post, if your unit tests are precise and truly cover a specific behavior, it is easier for a future developer to learn and join the rest of the team in mastering the domain. I won’t get into the multiple xDDs you can practice to achieve this, just as long as you have a way of doing it. We practice a mixture of Test-Driven Development, Domain-Driven Design, and Behavior-Driven Development/Design.