Agile development where customer collaboration is difficult

Question

The agile manifesto states

Customer collaboration over contract negotiation

My question is how do you make this work effectively when there is distance between the developers and the users?

I currently work in a "waterfall" team maintaining a large enterprise system. The customer is in a different country but we do have people travelling out most weeks. Once onsite though it's rare you get to speak to end users as it's a large corporation with several layers of "the business" in the way. So the distance is not just geograhpical and it won't be the same people going out every week.

I know agile could help us to give a quicker turnaround but I'm trying to picture how we can replace these unwieldy documents today with short user stories that get fleshed out via customer collaborations. We do collaborate when writing specifications but meetings have to be organised usually with lots of people brought in which doesn't sound very agile.

I'm also not sure where the product owner would fit in. This is a large system and the customer has different contacts for each part of the system. The development is all one big team though and each release it will be different parts of teh system that get worked on.

I have worked in a scrum team at a different company but I'm not sure it was very agile. There the BA's wrote a spec for each story and then the developer would code from the spec. This approach seems to lack collaboration and is document heavy. It did at least break things down into smaller chunks which were more manageable (no bad thing) but it doesn't seem to meet the benchmarks set out in the agile manifesto.

Answer 1

One of the main principals of Agile Development is customer being part of the team. It takes both parties to adopt Agile, so:

STEP 1

Get the customer on your side before proceeding. Agile is not about your team, it's about collaboration between YOUR TEAM and CUSTOMER.

Secondly, Agile is a methodology, it's not perfect, it's not a panacea, it's merely another way of doing things, that happens to work well for small teams with clients sitting beside them.

STEP 2

Learn the agile methodology and determine if it will REALLY make things faster and apply it to your customer. Large corporate clients are hard to get involved into projects, they tend to drag their feet and require comfort with plain old waterfall.

STEP 3

Probably go back to step 1 because your client is still not clear what is agile and why they need it... speaking from 6 years of experience with huge corporate client.

Some of the problems you are going to face:

• Client has been working with waterfall for years and is not willing to change, because waterfall gives them sense of security when they have timelines in advance(although timelines get blown out of proportions by 300% by the end of the project, but no one seems to see that)
• Client doesn't understand how agile works and agrees to it, then immedialy requires an L1 estimate provided by Monday next week.

• Your team has no idea what agile is, and process will be a constant struggle to connect people together while trying to get client on board as well.

  I know agile could help us to give a quicker turnaround but I'm trying to picture how we can replace these unwieldy documents today with short user stories that get fleshed out via customer collaborations.

You would spend a LOT of time trying to convert client to use agile and then the quality of user stories would be extremely low.

The right course of action in my opinion:

1. You know what Agile is and how it is applied very well.
2. You spend time and teach your corporate client overtime while helping them hire a couple BAs who are agile-savy.
3. BAs become product owners on the client's side and start EFFICIENTLY working with your team.
4. You break your team into smaller groups per area of the client's system and each team has own BA as product owner.

IT is also questionable if you can do agile remotely. I have seen some teams do it, and others have failed miserably.

Conclusion: Take your time, and make changes slowly. Pick a hybrid process that works for you and YOUR client. Collaborate with client and don't try to stick to a methodology 100%. Where there are people, there are adjustments to be made to yield efficiency. Don't strive to switch to Agile because "all the cool kids do it".

Answer 2

While significant supporting motivation and explanation was provided, the core question seems to be:

...how do you make this work effectively when there is distance between the developers and the users?

To me, this challenge is not unique to Scrum. Effective collaboration between geographically dispersed individuals is a common challenge. While the impact of this challenge may be greater on scrum, where collaboration is king, the potential solutions are still similar. They include:

• physical travel (as you mentioned)
• telephone conversations and conference calls (which I assume you might also do, but didn't mention)
• simple video conferences
• more sophisticated online collaboration environments, shared white-boards, etc.

Taking advantage of some of the above common solutions would probably be beneficial, regardless of the degree to which you have adopted Agile practices.