Skip to main content

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: , , , , ,