Agile Programming

If you’ve ever had to convince a manager of the value of agile programming techniques, such as test-driven development and pair programming, you know what an uphill battle that can be. But Mike Bria at InfoQ has just posted an article titled “How TDD and Pairing Improve Production,” which takes those anti-agile attitudes to task. In response to such common criticism of pair programming as “twice as many people writing half as much code,” Bria turns to Mike Hill who identifies the key to boosting productivity as a matter of improving internal quality, citing the following three proof points:

1. “Because internal quality and external quality are not the same things.

2. “Because the biggest single determinant in today’s production is the quality of yesterday’s production.

3. “Because typing is not now and never has been the bottleneck in writing code.”

So what steps can development teams take to ensure that their internal code maintains a high level of quality? Again, Hill provides the answer with three more things to consider:

1. “Write a microtest that fails before you change any code.

2. “Adopt a “no-pair no-keep” agreement.

3. “Establish a shared understanding of internal quality.”

You can take a look at the entire article here.

Posted: August 21st, 2009 under Agile Programming.
Comments: none

I’m always on the lookout for exercises and activities that illustrate some of the harder-to-convey issues in Scrum and agile. I just read a blog post by Certified Scrum Trainer Michael James that provides instructions for an exercise called “Planning a Party” that perfectly communicates the value of writing strong user stories and prioritizing them in a considered manner. You can take a look here.

It’s funny to think that something as simple as “planning a party” could better illustrate the function and value of user stories than something within a developer’s native environment, but everybody likes parties, so this one works great. As James describes it, participants are asked to imagine that their boss is throwing a holiday party for his co-workers and, in typical boss fashion, he wants the employees to do all the work! So participants are then given a list of vague and sometimes big directives and then asked to re-write them as agile-friendly user stories. Suddenly, questions about priority (which story is most important?) and order (which story should be completed first?) start driving the conversation. Before they know it, participants have simulated the same process of prioritization a Product Owner faces when prioritizing work and planning release dates. But since the context is immediately understood, it’s somehow less daunting than considering the same factors for a software project.

So who wants to plan a party?

Posted: August 12th, 2009 under Scrum.
Comments: none