Agile North Conference 2006 Report

Today was the annual Agile North conference held in Preston, Lancashire. It was a one day event with three different session tracks going on at once. Obviously there were lots of sessions that I wanted to attend but the ones that stood out the most were "Dealing with Customers" and "Storytelling with FIT".

The day started with a keynote speech from Rachel Davies who is a member of the Agile Alliance. It was great to finally meet a "face" of the Agile Alliance and to hear about how they formed and what their focus was. Rachel was a good presenter and kept the audience captured for the duration of her talk.
There was also a good amount of discussion in the Questions & Answers part at the end of her talk.

I had two key "take aways" from her talk:

  • Don't stick rigidly to the process if situations are changing
  • Get hold of a copy of "Waltzing with Bears" book

Dealing with Customers by Charles Weir of Penrillian

Charles held this session as a goldfish bowl (scroll down a bit) discussion forum and it worked really well. I've never seen it before and it was interesting how it really held the discussion to the inner circle rather than multiple conversations starting up at once. Charles was an excellent moderator and ran a very tight, focused discussion group.

My key take aways from his session were:
  • If multiple stakeholders are involved, get them to fight it out over the available (and normally very limited) resources
  • Gaining an onsite customer was very difficult so one company moved the development team to the customer (and located them in the middle of a call centre!)
  • Sometimes there is too much customer communication to the point of communication overload
  • In cases where no onsite customer was permitted, some teams resorted to more covert measures to access "real users"
  • Customers could get an update from the team by listening in to the daily standup.
  • To stop onsite customers disturbing developers, various "busy working" tokens were used to mark the times of day when the developer was coding rather than available for discussion.
  • It was generally agreed that when a developer was working on multiple projects at once it was more productive to get one project completed before moving on to the next. The perceived progress if both projects were worked on at once was misleading and productivity was actually reduced.

Storytelling with FIT by Steve Freeman (M3P) and Mike Hill (Mandu)

This session ran for the whole afternoon and covered what FIT was and how to implement acceptance tests in FIT as well as some very interesting exercises around the ideas of capturing, explaining and communicating requirements. Steve and Mike were an excellent double act, I particularly enjoyed their customer/developer role play around the capture of a large number of quirky requirements.

The predominant message that came across was that communicating requirements is hard work and requires lots and lots of communication between the customer(s) and developers. They require a domain language to effectively communicate, should focus on the "what" rather than the "how", readability is very important - use examples and descriptions to explain tabular data.

Again, here are my key take aways from this session:
  • For the specification to provide real meaning it needs to include both explanations and examples
  • It needs concrete acceptance criteria so that the developers know when they are done
  • When using FIT the real benefit comes when both customer and developer work together to create the FIT tests - they are "communicating" requirements
  • Production and collaboration are the important points when using FIT to create acceptance tests.
  • FIT test documents can be written in HTML, Word or Excel format (HTML is best as far as developers are concerned as it can be version controlled correctly).
  • One cost of FIT is the refactoring of the tests, this is not easily automated due to class, method and member names appearing in both the fixture code and the test HTML pages.
  • Full test coverage is binary - you either have it or you don't. It means that all code has a purpose and allows you to move quickly by giving you confidence in the codebase.

It was an excellent day and I'm really fired up to try and get FIT running our acceptance tests, I've been wanting to automate some of the testing for a while and JUnit never felt quite right. Can't wait to get into work tomorrow... ;)

Technorati Tags: , , , , ,

Problems with Trac and backported Subversion on Debian Linux

After installing the backported package of Subversion last week and importing a pre-existing codebase into it I decided that now was a good time to put Trac on the server.

Following my previously blogged Trac installation & configuration guides I was able to get Trac up and running fairly smoothly with one small problem: the "Browse Source" button was failing reporting some issue with "svn" being an unknown repository type.

After some searching and thinking I realised that this was most probably due to conflict between the newer backported version of Subversion and the older Python Subversion bindings libraries.

Here's how I resolved this issue:

apt-get remove python2.3-subversion
apt-get install python-subversion


Refreshed my browser and everything worked correctly!

Technorati Tags: , , , , ,

Installing Subversion 1.3.2 using Backports on Debian (Sarge) Linux

Following on from my previous posts about installing Subversion from source, here are some notes on how to do it using backported Debian packages.

Add the following lines to your sources.list file in /etc/apt:

# backports
deb http://www.backports.org/debian sarge-backports main contrib non-free


Update your Apt sources list:

apt-get update

Uninstall any old Subversion packages:

apt-get remove subversion
apt-get remove libsvn0


Install Subversion with 1.3.2 as a specific version (this causes the backported version to override the stable version):

apt-get install libsvn0=1.3.2-5~bpo1
apt-get install subversion=1.3.2-5~bpo1


Check that the installed Subversion is the right one by using svn --version you should get something like:

svn, version 1.3.2 (r19776)
compiled Aug 12 2006, 12:05:49
...


Install the Apache2 Subversion modules:

apt-get install libapache2-svn=1.3.2-5~bpo1

Follow my instructions on Configuring Subversion (svn) on Linux (Debian Stable).

There you go!

Technorati Tags: , , , ,