Agile Conference

The Cambridge Agile Conference is an annual event attracting Agile practitioners from across the region. It is two two days of keynotes, tutorials, reports and workshops delivered on topics ranging from complexity theories and their application in development processes to the use of physical or virtual scrum boards. The conference attracts some keynote speakers of international acclaim, this years were Dave Snowden from Cognitive Edge and Dan North, an independent consultant previously of ThoughtWorks. Also guest appearing at this years event was Dave Hart of IBM fame.....oh, that's me! Well, ok, I wasn't quite a keynote speaker, but I had volunteered, and been accepted, to give a talk about the role of developer in test, I will give an overview of that in a bit. This was my first time at the Agile conference, so I wasn't entirely sure what to expect, but the programme looked interested, and we have been using Agile development methodologies for a number of years now in this little corner of IBM so I was quite comfortable about the content.

Overall, the event was excellent, well worth attending. Other than the two keynotes I attended sessions on:

• Agile Innovation Practices - a talk more about how different styles of product can be innovative (new product, feature release and maintenance) than how to fit innovation into Agile teams.
•  Rapid Product Design In The Wild - a report on how one company took a product idea to a trade show, set up their stand like dev team and developed product prototypes live during the trade fair. 
• iPlayer for XBox - a report on how Agile was applied in the teams working on implementing the iPlayer for the XBox platform Scrum, physical or virtual walls - what the title says realy 
• Testing the Way to Faster Releases - a report about how a website development team reduced time to delivery by sharing the testing effort and making more frequent deliveries. 
• DevOps - an introduction to some of the tools and practices utilised in the field of DevOps, bringing server deployment into the development realm 
• Making Cross Shore teams work - a report on the pains and discoveries a company made making off shoring work. 

All the talks were interesting, and I learnt a great deal, my top three below, but I also found it quite affirming. Many of the processes and practices we employ here in the Cambridge Lab were mentioned as good practice during the talks.

Anyway, my top three:

1. Our estimating isn't as depressing as we might think! We are currently working in the complex phase of our product. Everything is new, lots is unknown, we are innovating all the time and our code base is still in its infancy. All these factors lead to a situation where estimating is very difficult, and often wrong. Advice given was to a) try and reduce some of the unknown before hand - technical spikes etc, b) embrace the complexity and factor that into your estimates - there will be things you don't know, factor that into your estimates as best you can, c) Don't beat yourself up when you are wrong - you will be. The nature of this phase of product development leads itself to estimation failure, learn from it and improve the bits that can be improved. 
2. Cross site teams take effort to make them work! This might seem really obvious, but so many people mess this up. It isn't enough to throw work at people and expect them to know what they are doing, Collaboration and coaching are key to making teams on multiple sites work. 
3.  A good test strategy is key to quality deliveries. Again this may seem obvious but many team simply throw untested code over at the qa function. The talk on testing for faster delivery was from a qa lead who is the only qa team member in her company! she essentially defines a strategy, polices that strategy (getting her hands dirty as well), but most of the testing is performed by developers in the teams. It was a great example of coming up with a process that a) ensured a quality delivery, and b) enabled the testing to be carried out at point of source. This led to a much more streamlined and timely delivery process. The key thought here were: don't bottleneck your process by putting all the testing in one place use the resources you have effectively accept that developer are actually pretty good at testing their own code fit your strategy in with your company, team and product structure 

So, onto my talk. I presented on the role of the Developer in Test. The presentation took the form of an experience report, and essentially detailed how our agile practices, and product roadmap had led us to the point of requiring a more technical testing role, a little about what the role involves and some of the benefits it gives us. The talk was well received, (no boos at least), with some good questions asked and a follow up discussion over lunch. I believe passionately in this role, and it was good to be able to share that with other Agile practitioners. In fact, it was good to hear others thinking about introducing the role, and even better to hear about those already doing so (even if they didn't realise they were!).

 Overall, it was a good couple of days. I learnt much, and think I had something good to share with others. We are proud of our Agile practices here, and I am proud of the progress we have made in bringing test into the development teams and to the forefront of our processes.