Many of us go to the gym and get good results initially. Once your body ADAPTS, the same procedure may help you keep up, but you won’t see any further gains and you may even start regressed.
I see the same problem with Scrum as a methodology for delivering software projects. The Scrum cycle, or the way Scrum is practiced, is either taken too literally or followed too rigidly.
What is the purpose of Scrum?
Scrum should define an achievable sprint goal for two weeks. Scrum should encourage teams to learn from experience, to self-organize when dealing with problems, and to reflect on their gains and losses for continuous improvement.
In my experience, Scrum unfortunately ends up breaking the core agile principle of people over process. This is largely due to poor management and the rise of certified Scrum masters.
Regular meetings are for managers
The daily Scrum should be a 15-minute, time-limited activity for the development team to plan for the next 24 hours. Unfortunately, Standups has become a fixed mobile medium on JIRA notes.
Moving tickets across a set of lanes is a bit like counting lines of code as a measure of success. A developer can be productive simply because of the speed at which they move tickets. On the other hand, focusing on blocks can reduce the amount of work a good developer has to do on a challenging problem, making it seem mundane.
Self-organizing teams
When done well, Scrum encourages teams to learn from experience, to self-organize when dealing with problems, and to reflect on their gains and losses for continuous improvement.
In Scrum, as advocated by the infamous Scrum Master, you need to clear bills, and there is no actual check on the quality of the work, which is often left to the non-technical project lead. This encourages people to go into a void and focus on output code.
Mythic story points are no mystery
A story point is a unit of measurement used to express an estimate of the overall effort required to fully realize a product backlog project. Or at least they should be.
In my experience, story points encourage teams to play with the system. After several sprints where the goal is not achieved, the savvy project manager becomes afraid to bring too much into the sprints.
The fear of failure leads to small-scale story sprints, in which only minor projects are brought in to ensure their completion. The big picture becomes irrelevant, and focusing on small things can eventually derail a project.
I saw this firsthand on a project where every story had to have an automated test. These tests had high maintenance budgets, and the automated testing on this project brought development to a near standstill. When automated testing became the focus, incorporating development and maintenance processes into a two-week window brought the continuous integration build time up to two hours. The pipeline stalled and change was forced.
The opposite of bringing too little into the sprint is bringing too much into the sprint. Developers and testers cut corners while accumulating technical debt. The debt is never repaid, and the spinning plate eventually hits the ground, leading to massive and expensive rethinking.
Instead of relying on story points, we should track what has been done, not what we have estimated. I find this astonishing. If I want to know how long a similar job took, I want to know the actual time, not the estimated time. If all your stories are small enough, then you don’t need to estimate.
Retrospective work is boring
The purpose of retrospection is to reflect. We looked at what worked, what didn’t work, and what experiments we wanted to try.
Unfortunately, it comes down to putting the same post-it notes like “good teamwork” and “too many meetings” in the same swimming lane as “What went right” and “what went wrong” and “How can we do better?”
After the first vintage, it’s boring. The lack of imagination of certified SCRUM masters is a huge part of this, but I find the current retro a tired and tedious waste of time.
Hackathons and hands-on events may be better than trying a retro approach to new models. Collaboration is implicit in hackathons, and the only way to succeed is good teamwork. Working on an interesting problem and having an imposed deadline ensures learning.
The recitation forces people to go into a room twice a week with a “let’s do it now” mentality. It will become repetitive and boring, and lifeless. The team needs a new stimulus, not the same extra two-week marmot sprint.
Let’s review Scrum
Scrum is often the enemy of productivity, and it makes even less sense in the distant, post-COVID world.
The premise of Scrum should not be that a cookie Cutter fits every development team on the planet. Many teams simply follow a script, with zero evidence of effectiveness. A recurring nightmare of splicing, sprint combing, sprint planning, and retrospectives only leads to rigidity. SCRUM does not advocate new and fresh ways of working; rather, it advocates repetition.
Let good development teams organize themselves around their situation. Track what was shipped into production plus the time spent afterwards (in days!). And track it.
Focus on reality, not some vague and understandable schedule. Automate all you can and have a super smooth pipeline. Eliminate all waste. Keep recalculating as you learn more. The idea that you are estimating and sticking to your fairy tale points when you know the least at the start of your work is untenable.
Grown-ups playing plan poker is as ridiculous as it sounds.
The postWhy scrum is becoming irrelevantappeared first onLogRocket Blog.