I’m looking forward to being part of an interesting conference, and hopefully helping to lift the profile of EVM in New Zealand.

Link to presentation abstract

( The abstract’s reference to “Number 8 wire” may be unclear to overseas readers :-)  The phrase simply means “New Zealand ingenuity”, in this part of the world.)

By the way, this means commenting finally works properly again.

My full presentation is here, although sometime I hope to isolate the middle section (on workplace interpersonal skill) so it can be viewed as a stand-alone 15-min presentation. [Done] As it stands, the presentation is 30 minutes on these topics, with 5 mins of questions at the end.

Virtually all the presentations are up now. If you’re wondering where to start, I can recommend Kay Johansen’s excellent session on Agile Testing, which I learnt a lot from; and Jeff Patton’s two-part workshop on story mapping, because story mapping is such an important idea. (And Jeff made it so interesting, it didn’t seem like it was 3 hours long.) I thoroughly enjoyed the whole conference, and can recommend every session that I attended. Now that the videos are up, I’m looking forward to seeing the ones that I missed.

If you like this blog (and presumably you do, since you’re reading it ;-)  I think you’ll love the conference.  It’s a new and different kind of agile conference, focussing back on the core principles of the agile movement.  In one respect, it’s like a giant retrospective for the agile movement as a whole — but it’s also much more than that.  For details, see this page on the conference blog.  I strongly encourage you to attend if you possibly can.

By the way, I’m presenting a session with the deliberately strange title of “Better Agile Through Stealing”.  (Thanks to Bevan Arps for the idea for the title.)  The talk is consistent with the material on this site, but most of it is brand new material which I haven’t blogged about yet.

Hopefully, I’ll see you there!

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.

I’ve just read a fascinating article on where talent comes from, over on Freakonomics.com.  It outlines research into the key factors that develop talent.  The key factors are:

"setting specific goals, obtaining immediate feedback and concentrating as much on technique as on outcome". [emphasis added]

For instance, life-long learning comes naturally to surgeons because they get instant feedback on the effectiveness of their decisions.  But similar learning doesn’t come naturally to doctors in fields where there is a  long delay between decision and outcome.

The research finds that development of talent is heavily dependent on the practitioner receiving prompt feedback on their decisions.  The timeliness of the feedback matters. 

Waterfall processes lack timeliness of feedback.  A classic example would be an analyst or architect making decisions at the start of a waterfall project.  Many months may pass before they learn the result of their decisions.  (Sometimes they never learn the result because they move to another project before the first one is finished.  Such so-called "experience" is of little value.)

In agile development, decision makers get feedback quickly.  Timeboxed iterations give feedback in a few weeks; unit tests give feedback in minutes; and paired programmers give feedback in seconds.  Research suggests this feedback doesn’t just improve the program; it also improves the programmers.

"You can’t have the same team do the same project twice; a bunch of stuff changes the second time around. You can’t have 2 teams do the same project; it’s too hard to control all the variables, and it’s prohibitively expensive to try it in any case. The same team doing 2 different projects in a row isn’t an experiment either.

About the best you can do is gather statistical data across a lot of teams doing a lot of projects, and try to identify similarities, and perform some regressions, and hope you find some meaningful correlations."

That’s exactly how Crystal Clear came about.  Alistair Cockburn spent a lot of time studying successful teams, looking for the similarities, then he documented them.  That’s not the kind of half-baked fad which Steve criticises, it’s about as scientific as it gets (in our field).  In fact, it was scientific enough to earn Alistair his Ph.D.  His doctoral dissertation is on-line and makes suprisingly easy reading.  I encourage you to read it, to see how Alistair grappled with the very problems Steve describes. (Eventually, he solved them much more successfully than Steve would expect. He documented his results as Crystal Clear).

Steve makes some very valid criticisms of the Agile movement.   However, his assertion of a lack of scientific rigour is incorrect (in Alistair’s case, at least).  Alistair conducted exactly the kind of research which Steve calls for, without any pre-conceived notions of what the outcome should be (he started years before the agile movement was founded).  He came up with a simple, effective process – which happens to be agile.

Interestingly, Alistair’s research-based process is somewhat different from XP.  As I’ve said before, XP is a subset of agile, not a synonym.

For instance: if the customer says they want a detailed Gantt chart, that’s a position. (It’s a position which is not very compatible with most agile processes).  But their interest is in understanding the status of the project. A chart like this might meet their interest equally well, while simultaneously meeting your interest in agility.

Customers also have a legitimate interest in protecting themselves from large cost increases and from large scope cuts.  Many agile teams unnecessarily adopt an incompatible position.

This is why its so important to understand that Agile is not just XP.  You have a much wider toolbox to draw on than just the practices in Extreme Programming.  Be prepared to draw on the whole toolbox, and your own creativity, to find the process that best suits your customer.  And be prepared to not use certain tools on certain projects.  For instance, this XP team (pdf) did not use pair programming; they replaced it with an alternative.

As agile developers, we know that good software is about customer-valued features. So is good process.