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:
- You know what Agile is and how it is applied very well.
- You spend time and teach your corporate client overtime while helping them hire a couple BAs who are agile-savy.
- BAs become product owners on the client's side and start EFFICIENTLY working with your team.
- 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".
Who should handle customer support within an Agile team?
"Customer Support"? Seriously, customer support is handled by a "Customer Support" team. It needs wildly different skills than programming, having a developer do that is in the same league as have him be the janitor or accountant. Maybe a specific developer could, but generally speaking, chances are it's a really bad idea.
Responding to user bug reports & creating stories/issues for them
This is a product owners job. Receiving feedback from stakeholders and getting them into shape for package of work for the team is the product owners main job.
Responding to negative app store reviews
Respond how? As in marketing? As in community relations? That's different jobs. And they need a different skill set than developers normally have.
Troubleshooting user problems
That may or may not be the developers job. Most companies have a different team to do this, too, but at least, of all those points, this is one that a developer should be qualified to do.
Responding to overall user feedback & feature requests
Talking to stakeholders is a product owners job.
Fixing urgent defects that were not known at the time of sprint planning
After prioritization by the product owner, as soon as the defect task/story is in the sprint backlog, that indeed is a developer task.
TL;DR
Customer support is a job. It's not something a developer does in their lunch break. You need a different skill set, too. You need to hire somebody for that the same way you would hire an accountant. You'd never have a developer do the companies books one day a week either.
Best Answer
We have the same problem in my company. There's a history of fixed-price, fixed-timeline projects, and our clients aren't generally very progressive.
Regarding development with no up-front commitments, I've heard so many fundamentalist agilists say, "I know it's hard, but you just need to push the benefits", or, "They might be skeptical but they'll see how well it went and come back to you next time". In some industries, maybe. In ours, that's a load of crap. I can't see any of our customers agreeing to just let us do our thing with no commitment on scope or price.
What we've found is that it's not always necessary to change the way you quote/bid/bill customers for an agile project. You can keep the agile process while sticking to your quote if you manage it properly.
Quote the way you normally would (with padding), and set some boundaries around the scope of the project. From that point on, follow your agile methodology:
But more importantly:
You're still using Agile internally and getting the benefits, but the customer is seeing a more familiar fixed-price, fixed-timeline, fixed-scope project. Any changes cost money and blow out the time.
The hardest part about this is setting the boundaries up front. It's definitely not something that can be done by just your sales guy, BA, or project manager. You need an experienced developer in those meetings. You need to nail down the areas that could cause problems and decide on expectations.