Today, agile software development is applied to the most of the projects and in case your team hasn’t used agile process frameworks yet, be ready that one day your client will come to you with an inspired expression on his face and say: “We must use agile!” And, for some reason, by “agile” most of the clients mean Scrum, so first it makes sense to read Agile Manifesto and its 12 principles and then proceed to learn Scrum basics.
However, after reading or even memorizing the Scrum guide you will not be able to apply it efficiently immediately. The Scrum guide is some kind of description of Scrum framework shortened as much as possible where every sentence is important and cannot be taken out. It makes sense to read additional books, articles, attend webinars or live trainings in order to apply Scrum effectively. Indeed, as it’s written in the Scrum guide, it’s easy to understand but difficult to master.
Unfortunately, I saw a lot of cases when Scrum was not applied fully or a Scrum team didn’t have all roles or artifacts. In the worst cases, the Scrum team simply conducted daily meetings and assumed they used Scrum. For sure, as I mentioned above, the Scrum guide doesn’t have optional components and if you apply Scrum partially, add extra roles or for example, describe artifacts in another way than it’s described in the Scrum guide it will not be Scrum and definitely, it may affect your effectivity. The Scrum guide gives you the very minimum that should be respected, it’s up to your team and your environment how to apply it but the key elements of Scrum should not be changed.
In this article, I will not explain Scrum theory in details but will try to describe what may happen if you ignore some of the Scrum roles, artifacts or events. I will also try to give some advice for difficult situations which most of the teams face in their Scrum projects.