Agile, Project management

Working at arm’s length

Sometimes a team that works closely together, with lots of continuous feedback, encounters someone or some body with whom they can’t do that. Perhaps it’s a company that delivers its system’s interface in quarterly cycles. Perhaps it’s a UX person who is going to deliver a single document after a lengthy research period. Maybe it’s a client who will have a determining view only at monthly meetings.

For such a team this can be a pain. But it’s important to be able to articulate that pain, because then it can either be revealed to be mistaken or addressed. And the consequences of such arm’s-length, or infrequent interactions is that the team often does not get a good opportunity to react to that input.

Therefore the team’s work and time has to be structured to cope with imperfect inputs in a way that doesn’t involve going back to the source. If the company providing the system interface only delivers quarterly, then anything they produce that is unexpected will incur corrective costs (in time or money) in the receiving team, until the next quarter when the team gets another chance to see another input. With the UX person who delivers once only, the team has to factor in the possibility that their input will be unexpected or uncoordinated with their own work. And so on.

Even if a team mostly operates iteratively, the cost of issues stemming from arm’s-length inputs will be higher than if they’d been more integrated, and the corrective actions will take longer.

Advertisements

Discussion

Comments are closed.