Agile versus business

On an agile project one of the core principles is an on-site customer. A customer embedded in the development team and available all the time for questions and to help clarify new features.
I realised this week that the reason this is so important is a timing problem.

The business works on long cycles, maybe quarterly sales targets or monthly reporting periods. A business query might need to be bounced to someone’s boss or discussed in meetings before a response comes back a week later.

The agile team works on a two week iteration cycle. When they have a query they want an answer now or the iteration stalls and time is wasted. So sending a query to the business sponsor and getting a quick reply in business time – next week – doesn’t really work.

So we bring in a permanent representative of the business to answer queries on how the business works and to make quick decisions on simple uncontroversial matters. Larger issues will still take longer and these may have to be addressed with separate investigation, design and implementation tasks over several iterations.

Many businesses see the advantage of this. They lose at least part of a business person but get software features released quicker. Maybe not more software features delivered but individual ones can go from idea to delivery much faster that in more traditional projects.

Agile versus non-agile

This is not the reason I thought of this. I don’t work on an agile project. My project is traditional large middle-aged business project with several months between releases and plenty of design upfront for new features to ensure the many existing users are happy with the change. There is still some frustration when the business can’t give immediate answers but we’re not wasting time as we expect that and there are plenty of other things to do before the next release.

But sometimes we interface with other development teams working to a different time cycle. Sometimes we are the provider for an agile team serving a smaller group of users with fast moving business requirements. Their two week iterations don’t match our three month release cycles well at all.

In a recent project the work was on the agile team’s future calendar but they couldn’t do any development without our new service. So they had to wait until it was done and then they wrote and deployed their end in one iteration.

That delay wasn’t the problem.

The problem was that because for them it was distant future work they had no idea how they would interface with our new service and had no real input into how the communication, presentation or performance was designed.

Bad for them as they later had to just take what we’d written. Bad for us as we had to write it blind and hope it worked when they tested it. Both of us wasted time later during testing making modifications.

We needed them to be available to answer questions during our development period. We needed them to allow time long before they might actually do any development to plan an interface that would work for both projects.

So in an agile project sometimes you need to be flexible with your schedule to meet the needs of the business or the needs of other teams. Because sometimes you need something from them. And then you are the customer.