My former colleague Alexandre Martins recently pointed me to a presentation given by Jeff Patton at Agile Roots titled 'Noone wants your stupid process' and it’s one of the most interesting talks I’ve watched recently.

In the talk Jeff cites globo.com as a case study of a company which is using an agile approach to development of their website but are starting to doubt whether it’s the best way to go about things.

In this part of the talk Jeff describes a conversation with the CEO of globo.com where the CEO pointed out that before they started 'doing agile' developers used to care a lot about the product that they were building but now they seem to only care about acceptance criteria.

I’ve started to come to a similar conclusion recently and I actually find it way more fun to work on writing scripts that others in my team will use because there are no acceptance criteria and I can concentrate on making it easy for others to use.

An interesting idea which I’ve never heard before is that of pulling out features if they’re not being used.

Presumably the thinking behind this is to simplify the product and make it easier for the user to use.

Patton goes on to quote a model which Jared Spool came up with for describing process:

Spool’s research suggests that if a process is written down and must be followed by people in an organisation i.e. a methodology then it’s very likely that the organisation will be failing.

On the other hand successful organisations used a lot of tricks and techniques and worked out what to do in the moment.

Patton also talks about owning the process rather than allowing it to own us i.e. we don’t want to become a slave to what the process says we should do.

My former colleague Toni Terreno has been talking about the stripped down XP/Agile process that he and his colleagues at Forward have been using which seems a pretty good example of owning the process to me.

Another idea that I quite liked is that of spending more time doing discovery rather than delivery i.e. learning about the world, imagining our solution, evaluating working solutions in the world.

Dan North talks about a similar topic in his 'Simplicity - The Way of the Unusual Architect' talk about half way through.

He also talks about the importance of learning about our users’s in context i.e. we should go to where the users are and see the problems they have and how they are/could use our product.

The last take away for me is that we need to try and find a way to measure the outcome of the product we’re building rather than the output.

Right now we probably measure the velocity in which we’re completing stories but we don’t have a good way of measuring whether or not what we built was valuable to our users.

I really liked this talk, I’d recommend watching it.