I presented a session at today’s Wellington Agile BarCamp.  The session was called “Crystal Clear: Big Lessons from a Little Process“.  Instead of describing all the details of the process, I outlined four of the most important lessons I have learned from it.

Here are some brief notes on the presentation.

Introduction

General background on Crystal Clear

Big Lessons that I’ve Learned from Crystal Clear

• Methodology-per-process.  How you can (and should) tune your process to the project at hand.
• Defusing debates about documentation, by recognising the two purposes of documents: supporting the current project; and supporting future maintenance programmers.  In my projects, I have found it best not to kill two birds with one stone.
• Shu-Ha-Ri, the stages of learning skills and how that applies to agile.  People at different stages have different needs for prescriptive process versus flexibility; and different comfort levels with finalizing process elements “later”.
• Simple = good.  The simplicity of Crystal Clear is backed by both theory and practice.  Its simplicity supports the design goals of Crystal, which are safety (delivering a successful project), efficiency (cost-effectiveness) and habitability (people are comfortable using Crystal).

Links to other resources

I mentioned various other resources during the presentation.  They included:

• Material on iteration lengths: why there is no real value in saying “my iteration is shorter than yours”.
• Collaboration: the Dance of Contribution.  A lengthy piece, with a lot to take in.  I skim read it the first time I saw it, but I got more out of it when I re-read it some months later.  My favourite bit: “No idea is rejected out of hand and no idea gets a free pass.”  I’m still learning how to apply it 😉
• Are requirements a document or a database?  I found Eric Sink’s article explains this dilemma very well.  (As for his comments about agile in the same article, I think he’s touching on an issue which James Bach described well here. Although they may not phrase it this way themselves, I’d suggest that Eric and James are both “Ri-style” practitioners, objecting to the over-emphasis of “Shu-style” agile.  As we discussed today, both styles have their place.)
• I also mentioned Eric’s “Career Calculus” page, and suggested that the same approach applies to process.  The most important thing is not where you start; but how fast you improve.
• Ron Jeffries on documentation.  His recommendations are broadly similar to the Crystal ones except (a) he has a firm view that the tests are the requirements documentation (Crystal is more flexible about how requirements are noted down) (b) he implies that you might not need future facing documentation (I would assume that if your software was worth writing, then it’s probably worth maintaining, which means it usually is worthwhile to write a future-facing document)

That all looks very brief, but on the day it took 50 minutes – honest.

By the way, I did it as an “incremental presentation”.  After each of the four main points, I paused for questions.  The idea was that each main point was like an “iteration”, and pausing for questions was like “releasing” that iteration.  It seemed to work.  We had good discussion after most points, and interleaving questions with presentation made it easier to fit the timeslot. (If all questions are left to the end, how much time should you leave?  Will people ask lots of questions?  Will they ask none?)

If you were there (or you weren’t) please let me know if you have any questions that are not covered in these notes.  Either leave a comment below, or email me.

Update 6 March 08:

I gave the presentation again today.  Here are some of the BA-related resources that I mentioned:

Scott Ambler on:

• Agile analysis
• Thoughts on the role of BA’s in agile projects
• Artifacts on agile projects

A couple of interesting points came out in discussion afterwards.  They included the idea of “emphasising facillitation over artifact creation”, the concept of ubiquitous language, and the notion that in some cases asking the customer to describe what they need is like a bunch of blind men describing an elephant.  Everyone you ask says something different, and what the business really needs might be different again.  In cases like these (where the customer organisation is, for whatever reason, unable to speak with a single authoritative voice) my thoughts are: don’t just say “that’s the customer’s problem”, or “we can’t do agile in these circumstances”, but instead apply BA skills to help the customer to articulate their needs.

Finally, here is the page on negotiation, which I mentioned at the end.