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.
Best Answer
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:
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:
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".