Pols Consulting

Rachel Davies, Steve Freeman, Duncan Pierce and I are running an Agile Summer school on the 18-12 august.

• Day 1: Intro to programming with XP version 2

• Day 2: Incremental Design with Mock Objects

• Day 3: Putting XP into practice with RoboCode

• Day 4: Acceptance Testing with Fit and Fit Library

• Day 5: Automation of Builds and Deployment

Each day is run using XP cycles with Planning Games, Stand-ups and Pair Programming. Workshops are followed by a clinic session that you can bring your coding problems along to for advice on resolving them.

More information can be found at http://www.AgileAcademy.net/summer/

I keep bumping into agile teams that do the popular techniques (such as TDD, pair and programming) but don’t get feedback from the real end users.  In most cases they fail and the proverbial shit hits the fan.

They simply rely on their one on-site Customer.  For commercial software (or companies that do not like developers and business customers talking to one another), a customer proxy (usually the product manager) is used instead.

The person playing the Customer role is one of the most critical.  The fact that most teams only use one person means they a single point of failure.  It does not matter how good the development team are, if they don’t build the correct software, the project will fail.

This can go on for months.  When the end customers eventually do see the finished product, they rebel and complain that it does not address their needs.

I have been thinking how to improve this.  I do not have any concrete answers…

I think the developers should spend time doing the work of real end users, or at least watching them where this is not possible (for a Pilot, Trader…)

They should socialiase together - it’s amazing how many issues can be resolved in a bar over a beer.

You want frequent releases to real users to get get early feeback.  In may view, teams who say they are doing agile, but fail to ship early releases to end users are missing the point.