Agile Quality

I just set up a new google group/mailing list called agile-quality.

Check it out here: http://groups.google.com/group/agile-quality

My initial welcome email says:

I intend it to be a place to discuss all aspects of software quality,
particularly as relevant to or involving agile principles, values or
practices.
This includes things like:

• What is quality?
• Quality Control
• Quality Assurance
• Relevance of quality to project managers/product owners/scrum masters etc
• Quality Management
• Testing (even though there is already a great agile-testing group)
• ISO 9001 Certification
• ISO 9126 Software quality model
• Other standards and models for software quality
• Technical debt and the management thereof
• Metrics for software quality
• Customer involvement in quality issues
• Discussing other “movements” or groups with a focus on software quality
• and agile
• Craftsmanship as it relates to software quality
• Software design; how it relates to software quality
• The Law as relevant to software quality.
• Discussing books, magazines, websites, blogs, quotes etc about software
• quality
• Which agile methods and practices specifically address quality and how?

I expect it to cover technical aspects of interest mainly to developers,
such as clean code design, as well as more managery type topics, such as
QA, certification and legal aspects, and everything in between. Ideally
this could be one mailing list where the two groups can mix, and form
consensus etc.
About me: I am just a software developer (and project management
student) interested in software quality and agile. I am not an author or
consultant (yet/at the moment). I don’t really have much of an agenda to
push except to discuss and learn more about software quality in agile
environments. I do have opinions and they will pop up in later emails.

Currently the list is unmoderated, and I will only change that if
spammers attack. Personal disagreements, teasing, slightly off topic
messages and banter will probably not be moderated away (at least for
now), I think such things help build community. The moderation policy
will be pretty loose but I reserve the right to make changes if it seems
necessary.
Thanks for checking out the mailing list, and enjoy!

Circling the drain?

I was just reading the XP mailing list and followed a link to a debate in the Agile blogosphere that seems to be a sort of XP vs Scrum type thing. Basically the popularity of Scrum means that people are adopting Scrum and considering themselves Agile without engaging in the appropriate development practices that XP provides. Some claim the direction of Agile needs to change, to put more emphasis on development practices and less on Scrum, or its the end of Agile.

I don’t intend to join in this debate, as I think both sides are wrong, but I will take the opportunity to write how I see it.

The word “direction” is interesting. As if there is something in the distance called Agile thats pulling us towards it. I guess thats how most business processes work. Someone has an idea, and prescribes it in the form of a concrete model that is supposed to be emulated. In such cases this concrete model looks indeed like an endpoint, towards which one finds the direction to be followed.

Agile is, to me at least, a bit different. Its more of a decidedly non-concrete set of principles and values. They don’t define an end point at all, hence no fixed, single direction. They define a starting point, from which more concrete practices and process are pushed out, or emerged. Once a team or an individual develops those principles and values as part of their culture, they exhibit certain behaviors that are influenced by those principles and values. They may or may not end up looking more or less like XP or Scrum. Different interpretations of those Agile principles and values, as well as principles and values outside of Agile, as well as subjective circumstances will mean that whatever emerges, is likely to emerge in as many different directions as individuals and teams that start from those principles and values. XP and Scrum are just head-starts along pretty good directions. I would suggest that a team that adopts Agile practices and processes only for planning while neglecting the development aspects or vice versa has made the mistake of neglecting the principles and values and seeing (some particular sellable concrete package of) Agile practices as a destination to move towards rather than a set of principles and values to guide the emerging of behavior. Hey at least they are a step above those who think Agile and Scrum are TFS templates though!

So rather than watching Agile circle the drains of concrete Scrum (and XP) practices, let it pour out from the values tap of the manifesto and the principles.

Forget about selling Scrum practices (or XP practices) as “directions” for Agile. Sell the principles and values and let the practices emerge, in all sorts of directions!