Tuesday, 21 February 2012

Agile Practitioners meetup - 'In Theory and in Practice'

Last night I attended an Agile Practitioners meetup where Daryn* gave a talked titled 'InTheory and in Practice'.

Here are my notes from last night and the Italics are my thoughts

He took us through a recent project (for a client) to build a Excel plug-in which connected to a third party.
Didn't really go into complexity, wonder if the same approach would work with a larger team.

TDD and BDD were used
BDD details weren't really discussed but it sounded more like acceptance tests were written rather then 'full' BDD.

There were 2 Developers and Daryn acted as a sort of co-ordinator.

The Deverlopers were able to practice pair programming and found having to voice and explain/justify your ideas a little odd at first but found great benefit by doing it.
Teaching/learning and writing better code

Code reviews were carried out by Developers on other projects.

Daryn also talked briefly abou the NUMMI case study, I'm not goint to write anything about that as there is loads of stuff around.
It's a good case study and I've not researched it enough but I wonder about the variables such as if the improvements were partly due to there being nowhere else for people to work and does that matter (in terms of the fact there were huge improvements)

On the project the first thing they talked about was testing, or how much/what could be automated.

They used Specflow for automation and I think Coded UI may have been mentioned as well.
            Were other options explored?

They were given uses stories which contained impementation details and luckily they were trusted enough to re-write the stories and change them to just the what rather than the what and how.  This meant they could look at different ways of implementation and were able to simplify the solutions.
            Were they written with the people who write the original stories?

They were able to decided at the last responsible minute and Daryn shared some pointers:
* Share partially completed designs
* Colloborate
* Develop a sense of how to absorb change
            What did they do to develop that sense? Or how was it handled?

All the stories were based on business value only and nothing had been written for the implentation, frameworks, etc. Essentially all the kind of stuff that becomes tech debt.

This also meant that this work wasn't visible.
            It was mentioned that this wasn't a issue, be interesting to know why this wasn't a issue.

A couple of burn down charts were shown and generally speaking they were pretty smooth and showed improvement.

Excel was used as the overall management and data collection tool

Of high importance was the people side of things, building a good relationship with the PO and the third party.

Daryn shared some general project pointers:
* Don't do too much upfront
* Too large a context change/switch can cause performance hits, ie, work on 1 project, don't work on multiple projects.

Data, information and quotes were resourced from Jerry Weinberg, Lean SoftwareDevelopment*, The New New Product Development Game and various conferences.

*Didn't get Daryn's surname. 
*Not sure which actual book it was.


  1. Hi Tony,
    Thanks for attending the event.

    I notice you have a bunch of questions, I will try to answer a few to help give a fuller picture:
    The developers did not do 'full BDD', all of the time. This was the first time they were using an acceptance testing framework. They also had to learn a few new technologies to make it happen. With a test coverage of greater than 80% I am more than happy with the effort.

    SpecFlow was used as it is a low barrier to entry. It actually works very well, it was a better choice than something like FitNesse for this project. Coded UI was tried, but did not work with the Excel controls we are using. We are resorting to direct VBA calls from C#.

    The stories were re-written with the original authors there. This helped a lot, thanks for reminding me about that point.

    With regards to the last responsible moment. I mentioned that those three points were strategies to help delay decisions. I focused on the first two points in the talk. We really kept up a good communication with all steak holders.

    With regards to 'business value only' stories, I did not recommend that. I feel it worked on this project because developers were not pushed to take on new stories, it was a pull system. They could take time to do the non-business value, but essential work. Had the developers asked to put up tech stories we certainly would have.

    You got the Lean book correct.

    This project involved an Excel plugin, an internal web service and a third party data provider. It was a relatively small project. However, I was wondering what aspects of the approach are you concerned about for larger teams?

    Thanks for the write up, I hope you make it to the next event...

  2. Hi Daryn,
    Thanks for the post.
    When I mentioned the larger team concerns it wasn't really about the processed (which I didn't make clear, my bad) it was more about the people side of things which we seem to forget a lot about.
    The egos, bureaucracy, politics, all that lovely kind of stuff. :-)