February 8, 2018
I have been “using” scrum for good 4-5 years now and I never took a major liking in it. Some scrum masters have made it more bearable than others. At Arago we were also put into the scrum process and I think we actually took it seriously. And keep in mind that I mainly run in the start-up scene, so the team sizes and projects scopes are likely smaller and the tasks more broad.
Quote me on this: “An already functioning team does not require scrum”
Let me go over the main benefits that I always get told to fill out the “paperwork” and follow the process.
Sticking to the sprint & proving process
Idea from scrum: We need the process and the time estimations so that we can show to the management how things are progressing. This is all nice, but only comes in handy when things are already not working out. For example in a restaurant a customer walks in and orders food. He says what he wants and then expects us to start working on it. After a while the customer receives the food and all is good. Only when you keep the customer waiting with nothing to eat, will he come to you and ask “How is the progress, are you working on it?”. Same thing is software developement, only when you have shown nothing to the CEO, you will need to go on the defensive and start proving how you are making process. You see the scrum process is a way to secure us as a team against management. Which may be necessary for where you work, but I hope not for everyone. Keep in mind I am a frontend dev. but for all the bosses I have worked for, The Best solution is just to provide working examples of progress, appetizers if you want. Don’t keep the guy sitting without anything for an extended time. Build up the interest and trust that you are constantly serving him. Spending effort to provide “proof” that work is being done, but having nothing to show is a waste of time.
Dailies
I am a frontend developer, so I work closely with the backend and the designer. I need them to be reachable for me as much as possible, if I have a problem then I am going to ask that person for help. As easy as this and listening to 15 minutes to whatever has happened in the team, whereas it is already clear, because we work together. If the daily actually gave me information about team activities that I did not expect, then maybe we shouldn’t be called a team at all. The daily is advertised for the developers, but in reality is it actually for the PO and Scrum master, that want to know where the team is at. Which is fine, but also awefully close to micro-management. If it makes them feel good, why not, but just keep in mind that it won’t get the product out any faster. If I have been tasked with implemented CRUD then you can trust me with it or expect me to report back every day about whether the C in the CRUD is done.
Time estimation
Measuring team velocity, this is supposedly an important one, if you speak to your local scrum master. First things first: It is only useful for management, as a developer this is just an added task to do. Something nice to make a plot out of. If you are running a small team that truly wants to be agile and that has a goal, then you hardly need these fine grain estimations. Instead you need to have a vision where you want to go and what is the next low hanging fruit with the largest gain. Not whether a task takes a 4h or a day. We should use this time instead to align our vision and motivate each other.
The good parts
So there are obviously times where I can see that scrum and strict process can be quite useful.
- If there are people who are not communicative
- If the boss is very insisting and punishing
- If there are people that you need to watch every day
- If the managment is unable to communicate goals and you need to push back
The takeaway is that there are many reasons to choose scrum, but it is NOT a generic tool that will benefit you. It is something you consider applying when the team has run into problems. These are my 2-cents on it. More vision and common understanding.