Dangers of using SCRUM, Process management and especially RACI model

I have seen and been involved in designing processes and writing role descriptions in different organisations. Sometimes the work is really concrete and useful, sometimes it can become really high-level and filosofical.....time consuming, expensive and restricting. Here are some comments I would like to make on the issue:

-The level of detail needed in the models indicates how bad the relations and teamwork are in your teams. If it is on the level of "I take care of the technology and all around it" then you have a good team.

- Detailed and popular models like SCRUM and SAFe are necessary in teams where there are new members and or members from different organizations or cultures. The familiar methods make co-working easier when there is no time to build trust.

- Detailed role definitions and methodologies are dangerous. Even the most detailed descriptions and models do not take into account all the possible scenarios and it can easily happen that everyone does their tasks perfectly, but the system goes down or the development does not deliver. (MOKK - Minu osas kõik on korras / Minun osaltani kaikki on kunnossa)

- Detailed process models and role descriptions turn organizations into bee-hives: very effective in a status quo environment doing the same thing over and over again, but totally unable to adjust if change is needed.....and change as you know is a constant in modern business.


  1. - Detailed role definitions and methodologies are dangerous.

    I mostly agree, but I would add that they are necessary evil to a certain detail.

    In my experience the biggest problem with working with SCRUM teams is the unambiguous responsibility for the work. "We did what the customer wanted" is the most often heard excuse when things go bad. Now pay us!

    Nobody wants to take the responsibility for the fact that the work is no use for the customer's business.

    But in the other hand, if there is one person who "runs the show" and is responsible for the result then there must be processes and chains of command in place for reporting and metrics. That needs detailed descriptions what are we doing and how and who needs to be informed and whi has the power to decide those matters.

    That is very unSCRUM :)

  2. Yes, like always there are plusses and minuses. I wanted to just point out that process management and among others scrum in itself does not solve all problems.


Post a Comment

Popular posts from this blog

Misconceptions regarding electric cars

How to move to Estonia Guide (for ICT consultants, specialists....but for others also)

Desktop, Android, IoS usage on Recommy.com