The important thing is to develop an open, transparent and trusting relationship with the client. The customer needs to understand what your challenges – and cost – are to work in the manner you are being forced to work in. At the same time, you need to understand why is it that the client cannot deliver in a predictable manner. Once there is appreciation for both sides, usually solutions will emerge that will satisfy both sides.

But it takes time to get there with the client. There are a few things you could do to make it easier to have such a discussion:

1. Set up a Kanban board that highlights and visualizes the work being done by your customer and you. A simple example is the one shown below:

The board visualizes the process being used by both sides – and the work being done at any point of time. The numbers next to the column headers are WIP (work-in-progress) limits – the maximum number of work that can go on at any stage at any point of time. If you are the only worker on your team, for example, then the WIP limit for the entire second row should ideally be just 1. For now, ignore these numbers and simply put up the board with your and the customer’s process so you and the customer can see what is going on.

2. Work out an agreement with the customer on the minimum number of web-services that should always be available in your input queue. So, for example, the last column in the first row (Customer – Done) must have at least 2 or 3 web-services (minimum WIP limit) so when you finish working on one, you have a second one always available to start on. So, initially, you may have a bit of a lag as you wait for the customer to complete at least 203 web-services, but from then on, you should always have work to do.

3. The overall sequencing of the web-services depends on your overall design – and when you need which services broadly. That needs to be done initially, with some leeway given for the variations in the actual delivery that you have come to experience.

Based on that design, you might identify initially, the set of web-services you need to deliver each ‘feature’ or “MVP” (minimum viable product) – that you can actually demonstrate working.

The advantage of using the Kanban board is that you can use it to show the customer the problem you are facing much more effectively than by just describing it – a picture is worth a 1000 words – and probably 100s of 1000s of dollars! To build the board, you could use a physical board with stickies or an electronic Kanban board – especially, if your customer is in a remote location.

Hope this helps.

Well… this happens all the time, and going agile is not going to fix the issue, rather you could get the web service definitions / contracts finalized. At this point you could actually start to build your system with mocking of the client web service using some tool like SOAPUI.

Once the customer service is up and running, you can actually test it. Of course this is not the ideal solution but, if you do not have any other things that can be done during this period, this may actually save some time.

…how to plan the project so that my coding and implementation will start according to the delivered required web services?

It sounds like you already do such planning, but that the customer sometimes delivers late or out of sequence.

Should I consider using agile?

Yes, you should consider “using agile”. Whether or not you actually chose to adopt agile practices, or a Scrum specifically, should depend on your careful consideration of your circumstances… and not just the problem you have described here.

…how to use it in that case?

and

…how to deal with the risk of the delaying from customer?

Here, it would be easier to answer for the case of a particular method, like Scrum, rather than agile principles more generally.

With Scrum, the aim it to deliver high quality increments of a deliverable solution. Scrum gives priority to the quality of the deliverable, rather than its timeliness. With Scrum, essentially, the risk, and consequence, of delays is accepted. The customer, and their team delivering the component you depend on, after all, should be part of the Scrum team.