Agile Developer - Conference SOLD OUT!

Scrum was designed to achieve a hyperproductive state where productivity increases by 5-10 times over industry averages and many collocated teams have achieved this effect. Jeff will discuss projects where they have achieved this kind of productivity gain and why they succeeded.

Adopting Agile techniques is, like any change, difficult. The change to Agile techniques in particular can be very hard as they run against the grain of much of the received wisdom in corporate IT.

By focusing on value added rather than effort expended we can make Agile make sense for managers and business sponsors. By focusing on quality we can make Agile make sense for developers and testers.

Here are some data, some stories, some models and some techniques for managing this change.

Many agile projects are having trouble getting to grips with a steady growing number of user stories. This in turn makes prioritisation and planning difficult and frustrating, causing the team to make sub-optimal decisions in terms of what functionality should go into each release.

User story mapping is a simple way of collecting and organising user stories in a visual map. The map helps the team understand how to put together releases of real value to the business by taking the whole workflow into consideration and focusing on what the users want to accomplish.

This talk illustrates the problem, explains three strategies to deal with it, and introduces user story mapping as a tool for putting the strategies to life.

Over the last ten years, Test-Driven Development has grown from something exotic, that only a handful of people knew about, to near- commodity. So there's nothing left to say, right? I don't think so. In this session, I'll review some of the landmarks in the history of Test-Driven Development and what they tell us about how to develop software; the ideas, techniques, objections, and misunderstandings. I'll talk about my experiences of discovering TDD and what I've learned about how to do it well, how to adopt it, and how to bring it into existing code.

Keywords: TDD

Many organisations will tell you that they are "doing" continuous integration. A boat anchor of a PC in the corner running an old version of CruiseControl might tick a few boxes, but is it really effective? You'll find out in good time if somebody checks in a broken test or forgets to check in a file; it won't tell you if your code is likely to run in production. In our focus on delivering code, can we forget where the code will be running? You might be writing it in a warm office on a quad core Intel PC. Production might be a single core SPARC system in a cold datacentre or a dusty room.

As we get better at CI, we should start seeing our feedback loop extend out past development into other areas. But what strategies do we have for doing this and keeping the feedback loop tight for the developers? Does that matter?

This session will attempt to answer all those questions and more. The presenter will share his experiences of 5 years of being a professional build manager, using examples taken from real projects.