Agile Principle 6 – Close, daily cooperation between business people and developers

The sixth Agile principle is “Close, daily cooperation between business people and developers”.

The principle here is to get the business people and the developers working closely together, hopefully the result will be that the business representatives really help to shape the final solution whilst the developers also gain a deeper understanding of the business requirements.

Close cooperation can also help to support a culture of change, where missing or incomplete requirements can be spotted early and often addressed with minimum impact.

One ideal approach is to include someone from the business in the development team who can constantly work with the IT guys. This however may not always be possible, often the business teams run very lean and staff simply can’t be spared in this manner. In these circumstances short daily meetings with the developers are a big help.

An alternative approach that I’ve used to good effect is to actually relocate the developers to work in the business teams, you can’t beat sitting with the people who are (or will) actually use your software. It certainly helps to keep a focus on the end user.

It is also useful to constantly demonstrate the part finished solution to the people who will operate it, as this helps everyone get a real handle on how the software might perform when finally deployed. I have found that many non-technical people respond better to seeing the final screens than they ever would to a requirements document.

Another byproduct of this principle is a “no surprise” delivery. In waterfall projects recipients of the software often  had zero visibility until quite late on in the development cycle, it wasn’t unusual for user accept testing to be the first exposure to the new system. This can lead to a shock when people suddenly realise that their vision isn’t what has been delivered, resulting in significant costs / overrun. (Regrettably I have seen this exact situation arise several times!) Seeing the software evolve and contributing to the process removes this risk.

The time commitment from everyone involved shouldn’t be underestimated but following this principle is key to ensuring short sprints are effective.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s