Marcin Floryan

In a traditional waterfall project team the communication tends to be unidirectional. It starts with a customer stating their requirements and a business analyst capturing them. Then, there is the designer who takes requirements and turns them into some sort of specification, it lands with the developer and eventually gets to the testes. By the time these Chinese whispers end, the delivered software looks nothing like what the customer needed.

This is where agile methodologies come in and you start introducing all these new concepts. First, there is disbelief ‘So I am actually supposed to talk to someone?’, ‘Am I really, really allowed to ask the customer these questions?’, ‘Like it is OK to actually walk away from my desk and join the meeting?’… Given you’ve done enough training, coaching, persuasion and bribery people will eventually get convinced, become more enthusiastic about the changes and go for it. Now suddenly every one is talking to the customer! Great, people are engaged, customer is happy (is somewhat overwhelmed) and yet – things are not quite right. There is a bit missing? In a while, people start asking different questions ‘So now we all asked and all got slightly different answers, what do we do?’. Then you think – fine – let’s give them a collaboration tool to synchronise the efforts.

It is just too easy to fall into this trap, but what you really need is make sure that first and foremost the team is communicating internally (and scrum meetings amongst other things help). What you really want to achieve is a homogenous team that works together, and where everyone can, and indeed do speak to the customer but those communications are managed. That information is coordinated, that someone focuses on the testing requirements, another person on performance issues, yet someone else takes upon themselves. We’re all in it together – not only gathering information but also effectively sharing it and optimally capturing knowledge required to succeed.