Sven Malvik 
I’m very lucky, being a leader of an engineering team in a great Norwegian organization. The reason for that is simple. I can make things happen that are very important to me and where I have very strong opinions about, “Agile”. What does Agile even mean? In this blog post, I want to briefly discuss why I think Scrum and Kanban make us unhappy and slow us down, but also what’s important. The video below highlights some points of this post.
Avoiding the Agile Alignment Trap with DevOps
Why I dislike Scrum
“Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” What’s funny is that the explanation of Scrum uses the word people. To its defence, it also sets the focus on deliveries, not the people.
One trait of Scrum is to time box a set of tasks, typically 2 weeks. That requires from us to spend time on estimating the tasks and then agree within the team to commit to them, meaning We get the tasks done no matter what. What we forget is that estimates are estimates, not facts. Estimating takes time, but it’s invested time. We make sure that everyone is onboard and understands the tasks. There are a few problems with this approach. People get bored locked up in a room for some hours and get surly not motivated by such process. When the time comes and One or Two developers want to work with a task, we need to deep dive again, a second time. The rest of the team doesn’t really care because they work on different tasks.
At the end of a 2 weeks sprint, we run a demo showing stakeholders and other teams what we have build. The key stakeholders have already seen everything by then in most cases. Also, many developers don’t feel comfortable speaking in front of people either. I didn’t.
I didn’t like Scrum, especially those standup meetings in the morning where a team leader ask everyone 3 questions. What did you do yesterday, what are you going to do today, and do you have any problems where we can help you. This is poor leadership. Instead of giving everyone the feeling of being watched, we should prefer to show trust by being interested in the people and there work. Tasks are not important. The end goal is important. But the end goal can only be accomplished when everyone is happy and feels valued and being trusted. I run daily voluntary checkins. Everyone can talk but nobody needs to. As a leader, I know what’s important and I’m only interested in the status quo, not at this point.
Kanban has similar challenges as Scrum
“Kanban aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.” I like Kanban better even though it doesn’t even mention people. As if they don’t exist. The idea is to shift prioritized tasks as fast as possible from the most left column to the right one, from Todo to Done. It implies that one column should not have too many tasks. In such a case we, the developers, need to focus our attention on those tasks. I once was in a team where the team leader made one of the developers responsible for watching the Kanban board and got the title “Work in Progress Guard”. The same day I decided to leave this company.
Developers, developers, developers
The following article is a good but very dry read. It highlights the people as the 1st order project drivers. No system and no methodology gets work done. Work gets only done by the developers and the people around, and work gets even faster done and in better quality when we like to work at your place and have meaningful work to do.
The following 3 sections are extracted out of the great article Characterizing people as non-linear 1st order components in software development.
Developers are Communicating Beings
Exhaustive written documentation is not engaging, and it is a poor communication medium. The writer must guess at the audience. There’s no feedback to the writer, and the writer does not get to use timing or emphatic signals, vocal or gestural inflections. For those who still think a book is best, consider the excellent but difficult book Design Patterns. Imagine that instead of trying to extract the meaning of the Decorator pattern from the paper, you could click on the page and see one of the authors explaining the pattern in a video clip. They would, of course, rely on tonal inflections, gestures, and timing to get the idea across. The same is true for the documentation we produced for building our complex systems.
Developers Tend to Inconsistency
Lack of consistency is a common failure mode of us developers. Methodologies that require consistency of action are high-discipline methodologies. The thing is that we are struggling being consistent which implies consistent over a long time. People that were interviewed on projects were asked what caused them to succeed in the end. The single most common answer was, “A few good people stepped in at key moments and did whatever was needed to get the job done.”
Developers Are Not Static Elements
Some developers like to make lists, some don’t. Some work best nights, some work best in the morning. Some like deadlines, some don’t. Groups vary similarly. Some cultures prize public self-scrutiny, others shelter people from embarrassment, and so on. Methodologies are largely group coordination rules, and so a recommendation appropriate for one person or group will be rejected by another. What applies to a consensus-minded group might not apply to a culture in which people wait for the boss to make a pronouncement.
Conclusion
These are my experiences, and I totally understand that other developers have made different experiences. We are different, and that’s why there is no system that can fix everything. We are the 1st order, not systems.
