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.