0

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.

  • possible duplicate of Can Agile be accomplished without client involvement? – gnat Jul 3 '15 at 14:11
  • Thanks, I'll have a read of that. I did several searches before posting but didn't see anything like that. – Ben Thurley Jul 3 '15 at 14:13
  • Both of these questions are different to mine. The first is about a customer who wants to carry on with a waterfall process. I think our customer would buy in to agile, I'm just not sure how to easily make it work? The second question is if you have a generic project with multiple customers but this isn't our situation at all. I'm interested to hear peoples experiences on large enterprisey solutions with many different suppliers etc. – Ben Thurley Jul 3 '15 at 14:20
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".

  • With your 6 years experience did you accomplish switching to agile and was it better? Our current process wastes a lot of effort on huge documents that are unwieldy and then bits get missed in development. It defintely needs to change and my gut instinct was to try scrum but in particular agile. The agile manifesto seems to address all of our main problems. It's how do we put it into action that's difficult! – Ben Thurley Jul 3 '15 at 16:50
  • We never adopted full agile, we however adopted a hybrid between waterfall and agile that worked very well. You speak truth, and you probably see real issues that can be fixed, however you are dealing with huge organization here and it will be very hard to change their ways. In 6 years I learned that a lot of politics in involved into development in large companies and you have to be very careful with the way you promote changes in their process. I could write a whole essay on this topic honestly :) – Alexus Jul 3 '15 at 16:55
  • But in short, strive for the best, but give client time to adapt and understand - and NEVER argue with them, rather persuade and again give time to absorb the idea and let it grow on them. – Alexus Jul 3 '15 at 16:55
0

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.

  • Yes that's the question. We already do most of those things to some extent although mainly it's a case of sending a document back and forth with alterations until it gets signed off. The thing I struggle to see happening is the kind of adhoc JIT collaborations that most agile processes seem to advocate. I get why that may be a good thing but surely it's not always practical? What then? – Ben Thurley Jul 8 '15 at 23:28
  • Is there a challenge to conducting good quality online collaborations "JIT" as you described it? Is this mainly concerning time-zone issues, or a lack of shared tools? If the later, it is more readily addressed. – David Jul 8 '15 at 23:36
  • Time zone isn't a problem and it's not so much about tools. Typically there are a number of interested parties so with one big spec you get meetings to go through the document with everyone present. It takes time to organise such meetings and everyone wants their say. I'm struggling a bit to picture how this could be broken down. I'm not saying agile can't work, I think it could help a lot. I just wonder how people deal with it on large enterprise projects. – Ben Thurley Jul 9 '15 at 0:07
  • So, are you saying that your question really has nothing to do with the "distance between developers and users" that you mentioned in your question? Your comment seems to imply that the overhead of organizing meetings would impact on your ability to "do agile" regardless of distance. Could you modify the question, if that is the case? – David Jul 9 '15 at 0:14
  • The question already says the distance is not just geographical but also organisational. As a developer I get a user story that needs fleshing out with acceptance criteria etc. Then what? I might have a point of contact who you could call the product owner but they in turn need to talk to users, managers, sales and marketing, legal team etc etc. This is all 10 times harder if all these people are not in the same office. A document gives these people something to pore over and give feedback. – Ben Thurley Jul 9 '15 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.