Tearing down the walls

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.

It is time for Danish politicians to form an opinion on IT projects in the public sector

As in most other countries, public IT projects have a bad reputation in Denmark. It seems that most people think that the public sector is horrible at doing IT projects (much worse than the private sector), and that the majority of public sector IT projects fail.

This perception is caused by a number of very big IT projects failing, causing not only the loss of the money put into them, but also the loss of state revenue, due to necessary IT infrastructure not being in place in order to e.g. ensure that tax refunds are paid correctly.

In my opinion, the public perception is wrong on two areas:

1. The public sector is no worse than the private sector at doing IT projects.
2. The majority of public sector IT projects go well.

The reason for both of these misperceptions is that people don't hear about projects that fail in the private sector, nor about IT projects in the public sector that does well.

But even with this caveat, there is no doubt that there is uncomfortable large number of IT projects that fail in the public sector, having a negative impact on the Danish economy.

Given this, I think it is remarkable how little the Danish political parties seem to care about IT projects in the public sector.

The politicians generally seem to care only on the most superficial level, saying that the public sector need to get better at doing IT. If they go beyond that, they generally focus on ensuring that laws are not getting in the way of implementing new IT systems and work rutines.

I think it is great that they are willing to take a look at how the laws in a given area might get in the way of eg. digitalization, but this is not enough. The head of the Danish Business Authority, which has just gone through a fairly succesful five year modernization program, has stated that it is frequently not laws that gets in the way, just interpretations and existing workflows.

It is often not clear that the interpretations and workflows will get in the way of development of the new systems, before the actual development work starts.

So, in other words, it is not enough that politicians look at the laws, they also have look at fostering an environment, where it is not only OK, but pretty much required, for public servants to reevaluate interpretations and workflows. For this to be possible, it is necessary to get them directly involved in the IT projects, not only as end-users, but also as sparring partners for the developers. This requires that resources are put aside for this.

Another area where I'd like politicians to focus, is creating an environment where different ministries, departments, and agencies learn from one another. There are some great attempts at this on the local level (eg. some departments look around at other departments to see what works before they start up), but it has to be structured better, and the responsibility anchored in one place.

There are a lot of experience spread across the different ministries, departments and agencies, but all too often it cannot be easily located, and each IT project is cause of re-learning everything from scratch.

A good attempt of drawing on the experiences of others, is the use of IT-projektrådet to evaluate the risks of IT projects larger than 10 million kroner and to follow up on high risk projects.

This is only done to federal projects however, and not on projects on the municipality level or regional level, even when they are much larger than 10 million kroner.

Obviously there are other areas where politicians could, and should, form an opinion on IT projects in the public sector, but I think that the areas mentioned above are some of the more important ones.