SCRUM: Nomen est Omen

Part of the solution or part of the problem?

The IT industry promotes SCRUM as the best way to reach better results in projects. But is that really the case? Or this just a new name for something that has always been there? Or is there a revolutionary new view on IT development? As far as I am concerned the name pretty much indicates what the real issue is that will not be solved using SCRUM.

The users never know what they want

When you ask IT staff what the number 1 issue is in projects, there is a major chance that the answer will be: users never know what they want. That is why they thought it would be a good idea to join developers and users in one team and to let them develop new IT tools together. This should take place in an open discussion where not at once a solution is reached but new ideas are added through several cycles.

A great idea but not as straight forward as it seems. There is a clear signal that the IT staff is full of praise for Scrum but users never mention it. The name Scrum indicates what will happen in practice: there will not really be a team. In a rugby scrum two teams with opposite interests will fight for possession of the ball.

This is also the issue of Scrum and IT development. A user will consider their processes and tasks, and see IT as a supporting tool. But IT staff usually see their area as the central and most important area: we as IT can improve the processes and tasks of the organization. Because we know better than the "Business".

Nomen est Omen

In a rugby match the strongest team will win de scrum. Similarly in a Scrum IT staff will be the strongest team. IT staff is best trained in the techniques. Apart from that, the discussion is usually too much about IT tools, not enough about supporting the user’s processes. Winning the Scrum will be the goal, not the results for the user.

That is the reality. Where IT staff are positive about the results, developing Sprints is usually not really about improvement of the solution. They are usually about solving a lack of quality. Genuine improvement of effectiveness will usually not be realized by Sprints. At most inadequate prototypes will be improved.

IT as The Goal or as a tool

There is still a long way to go to bridge the gap between the “Business” and IT. As far as I am concerned the real solution is that IT will see that they should be supporting, not "leading".