It is pretty widely accepted that one of the major challenges for IT projects is communications between the different parties involved.
The above figure demonstrates how a traditional IT project works, and why communication is such a big issue.
The business have some wishes, which they give to the requirement people, who turns them into requirements, which are handed over to the development team. The development team then develops the system, and hands it over to testing. When the system is tested, it is handed over to operations, which puts it into production.
Such a process is characterized by each group being walled off from each other, often in a real physical sense. It is also characterized by a lack of communications between the groups.
This means that it can take a long time to find misunderstandings, and that the requirements tend to become outdated before they reach production.
SCRUM and other Agile methods have tried to address this in different ways, but even so, communications problems still exists.
The above figure illustrates an IT project using SCRUM. Here the developers and testers form one team, and the requirements specification is handled by a PO who represents the business.
Due to the processes in SCRUM, the communication barrier between the PO and the SCRUM team is reduced, but there is still a barrier. Also, in most organizations, the barrier between the business and the PO is unfortunately as great as the barrier between business and requirements people in traditional projects.
There is also a communication barrier between the SCRUM team and operations.
The fairly recent concept of DevOps have tried to address the
communication barrier between the SCRUM team and the operations people.
As the above figure illustrates, this is handled by embedding the operations people in the SCRUM team (this is obviously a simplified description).
Last November I was at a conference in Orlando, where one of the speakers were the PO for the SCRUM process, and he told us that there is a focus on adding DevOps to the SCRUM methodology.
Unfortunately, he also said that they are not going to do anything about adding requirements specification to the methodology.
This is, in my opinion, unfortunately, as it would help reduce the barrier between the business and the rest of the project, and between the PO and the SCRUM team.
So, what can be done instead, in order to remove the barrier between the business and the rest of the project?
Well, I think it will be hard to completely remove the barrier, but I think there are different ways of reducing the communication barrier.
These are, in random order:
- Embedding a business person in the SCRUM team
- Regular meetings
- Techniques such as story mapping
These can obviously be combined.
Embedding a business person in the SCRUM team
This is an idea that was introduced with eXtreme Programming, though it probably existed before that as well.
It is simply getting someone from the business sitting together with the SCRUM team.
This is often hard to do, as it can be hard to get people released from their normal position in order to place them in an IT project, even if they continue to work on what they usually work with. This is partly due to the, probably reasonable, concern that the person will have much less time to do their job. But it is also often partly due to the fact that many bosses don't like not having people sitting apart from their usual team. On top of that, it might be hard for the business to see the value of embedding the business person in the SCRUM team.
If you manage to get a business person embedded with the SCRUM team, it is worth regularly evaluating whether the business person is the right person for the role, or whether there should be a rotation of the business people, in order to keep the focus fresh.
Regular meetings
A simple, but effective way of enabling communication between the business and the rest of the project, is to plan frequent meetings.
The sprint reviews in the SCRUM methodology is one type of frequent meetings, but there should be other meetings, such as requirements meetings between the PO and the business.
These meetings can be used for presenting user stories before they are taking into a sprint, in order to get the input from the business, and clarify any unclear requirements. It can also be used to prioritize the requirements, based on the current situation, and to adjust the scope of the project, based on any developments.
Techniques such as story mapping
Requirements in SCRUM projects are often written as user stories, and there are some techniques that can be used while writing these, allowing the business to get involved.
One of these methods is
user story mapping.
No matter what technique is used, it is important that to ensure that the business are willing to get fully involved. If they are not committed, no technique will help reduce the communication barrier.
In conclusion, it is unlikely that it is completely possible to reduce the communication barriers completely in an IT project, but there are methodologies, concepts, and techniques that can greatly reduce them, allowing for a greater likelihood of the successful development of a system which fulfills the needs of the business.
One aspect I haven't touched on in this post, is the extra complications if the project isn't aimed at the internal business, but rather at customers outside the organization. External customers obviously adds an entirely extra complexity to communications, and is a subject for an entirely different blogpost.
