Development process in a highly dependent environment

Question

I was going through a question on PMSE when this question struck me. I have been working as a Project Manager for a software company.

Most of our work we get from an agency. The agency in-turn gets that work from some other agency, which may get it from some other agency or the direct client. At the end of this chain there is always a direct client (of course). The following are the two modes in which we get work:

We > Agency #1 > Agency #2 > Client

We > Agency #1 > Agency #2 > Agency #3 > Client

We had initially started following Agile for development, but we soon realized that it is not working for us. The reason being for each sprint, if we have any clarification required or blocked items to be taken care of, it traverses the route from us till the end client.

Under such situation the action items move up in the chain depending upon the priorities of the involved agencies or the clients. Many times, we don't get updates in one single sprint, it spreads to 2-3 sprints to get updates.

As and when we get work items, we analyze and estimate them and send them for approval which may also take weeks or days depending on the availability of the agencies' respective Project / Account Manager. The same applies for approving finished tasks, which is relatively quicker.

We know we cannot fully follow Waterfall like models as-is. We have been thinking of formulating and following a blend of Waterfall, Agile and V-model to make our lives easy.

Given the level of dependency that we have on various stakeholders, what overall development process shall we adopt?

Answer 1

I take a different view to the other answers on here. The problem here is, clear cut, project management.

The fundamental constraints appear to be:

1. Long lead times for work definition
2. Long lead times for work clarification
3. Long lead times for budget approval
4. Long lead times for work acceptance
5. Long turn around time for defect reporting.

Now scrum will not work, because scrum is very dependent on quick turn around times for work acceptance / work clarification. Kanban will not work because the blocking tasks will all be blocked on client communications, so the development team cannot throw more resources at it to move the task along.

So what can be done?

Firstly, improve the supply chain. Work with your customers to build trust to allow more direct customer <--> development team communications when the conversations are about task definition, business rules. These conversations should be restricted to the developers asking the end customer for technical information and technical decisions and supplying the responses back. Any information flow back to the customer should be handled through the supply chain (such as delays, costs, customer asking for supply of a perpetual motion machine or some other impossible task)

Build up a larger library of 'ready to go' or 'actionable' tasks. Tasks where the work is defined, clearly understood by the developers and the customer is happy for that work to proceed.

Schedule regular review meetings with the end customer for them to review current state of the work. Whilst it may not be known when the meeting is arranged what work will be demonstrable, this creates the regular pulse of end customer feedback to the developers to keep their direction in line with their customers perceived needs.

Finally, accept that at times work will be blocked because of customer communication delays. You can handle that internally by having work for other customers that can be scheduled, by taking a guess at what the customer will ask for whilst waiting for the answer - accepting that you could be throwing work away, or having staff on a contract basis so that you only pay them when you have work available (ohh hang on, that's what your customers have done...)

Answer 2

TL;DR

You don't have a dependency on multiple stakeholders; you have a process failure at the interface between you and Agency #1. Shopping for alternative methodologies won't fix the process problem, but addressing it directly might.

Re-Define Your Stakeholders

From your description, you don't have any direct contact with the end user. While they may be stakeholders in some abstract sense, from your description you have exactly one client interface: Agency #1.

The fact that this agency may have stakeholders of its own (and so on down the line) should be irrelevant to defining your communications interface with Agency #1. If you aren't allowed to communicate directly with Agency #2, Agency #3, or the end user, then they should be excluded as stakeholders from your internal process.

Re-Assess Your Process

You have a number of ways of dealing with excessive delays in communications. Some examples include:

1. Define timely communications in your contracting process.
2. Adjust your sprint length for each project, based in part on the cycle time for communications.
3. Articulate the need for closer engagement to your counterpart at Agency #1.
4. Ensure that communications delays are a visible cost to the project.
5. Ensure that communications delays are a visible cost to Agency #1, since they are the company that pays your company.

You can't paper over a fundamental process problem by switching methodologies. There's no silver bullet; you must address this issue head-on. The project management framework you choose isn't really relevant to solving the problem at hand.

Answer 3

I am inclined to think that more than a process change your team needs a relationship change.

I think you guys need to get "closer" to the eventual client.

How about building up a case upstream on

1. Escalation - highlight the impact the current process is having i.e delays in delivering , clarification,sluggish communication

2. Shorter feedback loops - Coming up with ideas on expediting communication channels with the client (e.g. daily/weekly virtual stand ups/conference calls directly with the client/decision makers ?) .

3. Push back - Advocating not picking up stories/committing where there are too many unknowns. This will further highlight the pain that you guys are experiencing

I am sure not what the political culture is in your relationship with those agencies so you would need to be careful with balancing this diplomatically so that the agencies dont get threatened or feel ostracized. So, the message needs to reinforced that this is strictly about improving communication & facilitating quicker decision making.

Answer 4

Have you considered Kanban?

This is Lean, pull process that looks like good fit for your situation.

Here's what you can do and how you can benefit from Kanban:

• Map Value Stream and make it explicit to the stakeholders (agencies) how you cooperate with them
• Introduce Work In Progress Limit and show where bottlenecks are - agencies will see how much it costs them to have you blocked
• Track Cycle Time and Lead Time to show how much time you spend to items and how much you wait for sth (e.g. requirements)
• Invite stakeholder (agency representatives) into Kanban Operations Review where you discuss your whole pull system and use data provided in above points to optimize system.

Kanban is about optimization, but even more importantly it's about greater predictability. After some time you would get better data on average time to complete one item. Armed with those you could try to influence your stakeholders -> agencies you cooperate with.

Here's good Kanban link for you to start: http://www.leankanbanuniversity.com/introducing-kanban