Hi, as most of you, I've worked on diverse companies, each one with different cultures, policies and rules, but all they work with people, and at the end the target is the same. Finish what you need to do!, well, sometimes is not that easy, constants delays, changes at the last moment, nightmare deadlines create the conditions to a perfect storm, that usually translate in extra hours, extra efforts and a lot of coffee and stackoverflow.
I've worked in companies with total "Freedom" to manage your projects, where you can choose frameworks, libraries and even the methodologies (and in a few of places the methodologies used is no methodology at all), but in the most of the offices today I found that there's a lot of people who talk about "SCRUM" as the holy grail, the secret tool that will make all your projects finish at time, make all your devs happy and make the company the best company of the world.
Works with SCRUM is not magical, you have roles, ceremonies, and a lot of planification. I’m not saying that SCRUM or any other agile methodologies is a bad option. It's very good if all the member of the team understand his roles, respect the object of the ceremonies and are machines able to estimate with a 100% of accuracy the time and effort for a task. Here you will find a list of common errors that will make SCRUM not your best choice.
When a planning is a status, and the status is a grooming, and the retro is a forum and go on…
Is very common among the member of a team lose the focus of a meeting, for several reasons you can find yourself talking about a task of the next sprint in the current planning. This is usually a sign that you’re not taking the advantage of the current meeting. If the team is not coding, validating of doing something because they have to go to a meeting, they should respect the objective, and is a job for all keeping in that way. Planning is to planning for this sprint, retro is to understand what happends in the sprint, status is to talk about the current status and stand up is to say what're you doing, sounds silly but you should respect your ceremony.
When the stand up is at 11am, but the monday is at 10am, the thursday is at 3pm, the noon days will be at 12pm and for the nights of moonlight will be a 12am.
The stand up should be the most fast, easy and clean meeting of all the ceremonies, what’re you doing?, what are you going to do?, and if you are blocked ask for help. The development work is doing with the head, you shouldn't force your team to stop his work and concentration to attend a stand up in a not schedule time. The Stand up should be always at the same time to create the habit.
When each retro you find yourself with a lot of not finish task, and you’re not open to change anything
This’s the most important reason to don’t use SCRUM. If your team doesn't finish his work and you aren’t open to change anything in the way that you’re doing right now, you’re losing your time. One of the great things that Agile give you is the chance to catch the delays and try to identify the problems, and base on that apply the possible solutions. Remember that you’re in software development the changes are inevitable.
When your have more time of meeting in a week that actually development
This’s a sign that your salary is to assist to meetings and not to development.
When you can pass weeks without talking with the PMs, or any of the owners of the product.
The communication is vital for any team and project. If your team is working hard to get the project done, but any of the PMs are there to check what’s going on, involve in the creation of the stories and the definition of the goals. You’re not in SCRUM, you’re in a bad implemented Waterfall
When your team is always talking about how much they hate SCRUM
All the team should be ok with the methodology. All the team should be compromise with the way of the things are been doing. The team using SCRUM should be the most Agile fanboys of your company, otherwise you will have a not motivated team.
How you see this blog should be named “When you don’t use SCRUM correctly”, but the name was decided already, hope this small list of common errors helps you to understand better SCRUM, and share with your team to see if you're on the correct path.
In the code we Trust!
Top comments (0)