Real-world Agile for financial services product development

Author: Alan Brown

Software development has changed beyond all recognition in the few short years since the publication of the Agile Manifesto in 2001.

Agile methodologies have thrived at the expense of traditional ‘waterfall’ project management because they fit more closely with the way that people think, feel and behave and therefore deliver better results.

That’s why we use them.

If I never see another Gantt chart… 

Adopting Agile means focussing most of your energy on the next few sprints or iterations. We accept that the only certain thing about the future is that it almost certainly won’t look the way we think it will now. So we’ve said goodbye to 24-, 12- and even 6-month road maps because we don’t think their return on investment is worth it – they’re not useful or accurate enough for the energy they take to do well.

Of course that doesn’t stop clients asking for them – because they work differently, they aren’t software houses and some of them do have 24-month plans.

The trusted, traditional Gantt chart is usually the first document that the client will ask for; to map out tasks, features and releases far into the future.

There are Agile techniques for estimating that far out but proscriptive long term plans remove one of the great business benefit of Agile – the ability to adapt quickly to a changing market.

We understand that different organisations have found different ways to work so where we need to produce and work to a 24-month Gantt chart we can. We’d prefer to be more nimble than that but the development team will still use many Scrum techniques in their internal delivery.

Bending the rules on co-location

Agile is better than Waterfall but it isn’t a silver bullet; it requires (literally – it’s in the rules) continuous reflection and adaptation. And Agile methodologies aren’t Biblical texts either; they are there, just like the software they produce, to be questioned and adapted.

One area where I’m happy to break from Agile orthodoxy is co-location.

Agile practices like Scrum or the Crystal methodologies prize co-located teams. Everyone on the team (the whole team responsible for delivering the project, not just the developers) should sit together, they say.

It’s a brilliant idea because co-located teams communicate differently than teams that sit apart. Co-located teams are steeped in the project and experience what Alistair Cockburn, one of the founders of the Agile movement, calls ‘close communication’ in large teams or the more exotic ‘osmotic communication’ in very small ones.

But Alistair Cockburn also talks about putting properties before procedures and that’s the key to bending the Agile rules. As Cockburn puts it:

  • The procedures may not produce the properties. Of the two, the properties are the more important.
  • Other procedures than the ones I choose may produce the properties for your particular team.

In other words, what matters is how your team behaves, not what they do to get themselves to behave that way. Some of the behaviours that Cockburn looks for from co-location are:

‘Does it take you 30 seconds or less to get your question to the eyes or ears of the person who might have the answer? Do you overhear something relevant from a conversation among other team members at least every few days?’

Whilst Agile has risen and risen another phenomenon has also swept through software development at the same time; distributed, open source development. It is the antithesis of co-location and yet it works extremely well.

A generation of technology has grown up around that culture – technology that allows distributed teams to communicate effectively – and because of that I favour a more modern reading of the Agile insistence on co-location that reflects the capabilities of modern technology (and modern developers).

At Intelligent Environments we have teams in Kingston-Upon-Thames in England and Belfast in Northern Ireland. We think the rewards of expanding into different territories are well worth it but we’ve had to work hard on communication and collaboration to ensure that, having adapted the procedures, we deliver the principles.

Image © vallepu

22 Apr 2015

Author: Alan Brown

Software development has changed beyond all recognition in the few short years since the publication of the Agile Manifesto in 2001.

Agile methodologies have thrived at the expense of traditional ‘waterfall’ project management because they fit more closely with the way that people think, feel and behave and therefore deliver better results.

That’s why we use them.

If I never see another Gantt chart… 

Adopting Agile means focussing most of your energy on the next few sprints or iterations. We accept that the only certain thing about the future is that it almost certainly won’t look the way we think it will now. So we’ve said goodbye to 24-, 12- and even 6-month road maps because we don’t think their return on investment is worth it – they’re not useful or accurate enough for the energy they take to do well.

Of course that doesn’t stop clients asking for them – because they work differently, they aren’t software houses and some of them do have 24-month plans.

The trusted, traditional Gantt chart is usually the first document that the client will ask for; to map out tasks, features and releases far into the future.

There are Agile techniques for estimating that far out but proscriptive long term plans remove one of the great business benefit of Agile – the ability to adapt quickly to a changing market.

We understand that different organisations have found different ways to work so where we need to produce and work to a 24-month Gantt chart we can. We’d prefer to be more nimble than that but the development team will still use many Scrum techniques in their internal delivery.

Bending the rules on co-location

Agile is better than Waterfall but it isn’t a silver bullet; it requires (literally – it’s in the rules) continuous reflection and adaptation. And Agile methodologies aren’t Biblical texts either; they are there, just like the software they produce, to be questioned and adapted.

One area where I’m happy to break from Agile orthodoxy is co-location.

Agile practices like Scrum or the Crystal methodologies prize co-located teams. Everyone on the team (the whole team responsible for delivering the project, not just the developers) should sit together, they say.

It’s a brilliant idea because co-located teams communicate differently than teams that sit apart. Co-located teams are steeped in the project and experience what Alistair Cockburn, one of the founders of the Agile movement, calls ‘close communication’ in large teams or the more exotic ‘osmotic communication’ in very small ones.

But Alistair Cockburn also talks about putting properties before procedures and that’s the key to bending the Agile rules. As Cockburn puts it:

  • The procedures may not produce the properties. Of the two, the properties are the more important.
  • Other procedures than the ones I choose may produce the properties for your particular team.

In other words, what matters is how your team behaves, not what they do to get themselves to behave that way. Some of the behaviours that Cockburn looks for from co-location are:

‘Does it take you 30 seconds or less to get your question to the eyes or ears of the person who might have the answer? Do you overhear something relevant from a conversation among other team members at least every few days?’

Whilst Agile has risen and risen another phenomenon has also swept through software development at the same time; distributed, open source development. It is the antithesis of co-location and yet it works extremely well.

A generation of technology has grown up around that culture – technology that allows distributed teams to communicate effectively – and because of that I favour a more modern reading of the Agile insistence on co-location that reflects the capabilities of modern technology (and modern developers).

At Intelligent Environments we have teams in Kingston-Upon-Thames in England and Belfast in Northern Ireland. We think the rewards of expanding into different territories are well worth it but we’ve had to work hard on communication and collaboration to ensure that, having adapted the procedures, we deliver the principles.

Image © vallepu