Beyond Agile and Scrum: Great Leadership Matters More Than Methodology
The word “agile” these days is a synonym for SCRUM, yet it has nothing to do with it. Scrum is a synonym for poor performance within software engineering teams, primarily the Scrum implemented “by the book”. It doesn’t work, and we all know that, although now everyone acknowledges it. People who are stuck in empty scrum-related roles like Scrum Master, sometimes called Delivery Manager, will still paint the picture of how fantastic the process is, and I’m actually not surprised. Not often in a job, you can do little work, be paid well and have no real responsibility for the outcomes.
There is no one-serves-all solution. A team’s performance, efficiency and happiness come from outstanding leadership, not a methodology.
I have experienced enough flavours of companies to have a good understanding of what it is all about. Some of these organisations needed a process; some were transitioning into Scrum or moving away from it, whether a large corporation or a small startup. My most important learnings came from places where businesses felt they had to do something better but didn’t know how. They were not obsessed with specific ways but just wanted someone who comes in, identifies the issues, and knows how to move forward from there, get teams working efficiently, and shit finally done. That’s vital and not numbers, story points and other abstractions that have been put in place only to make a few high-level managers feel better about themselves and in control because they clearly have no clue how their organisation works.
Agile is not about the process, but attitude and exection.
Being agile has nothing to do with a methodology but with how organisations move through inevitable obstacles that affect their business and, in the current context, their software engineering teams. Agile means flexible, where teams can stay focused on tasks ahead of them but change the direction when necessary.
Agile: being able to move quickly and easily
No undertakings are set in stone forever. A team can be in the middle of a big project when shi(f)t happens, and the current direction no longer makes sense. Truly agile organisations can move away from things that don’t serve them — without ego, emotions and drama. It’s usually a painful experience but also a learning opportunity. It only becomes a massive waste if they don’t learn and make the same mistakes repeatedly, which is called “being stupid”.
Don’t treat people like children; it’s not a kindergarten.
The rigid Scrum rules put limitations in place. Letting teams be flexible in their working methods and directly influencing projects is one of the best things leaders can do whenever they have five engineers or a whole technology group responsible for code, infrastructure, and security. People don’t need to be told daily how to do their job unless it’s a dysfunctional team, but that’s a different story!
Every company is unique, and there’s no one-size-fits-all approach. Great teams are built on genuine connections, relationships and care. It’s not the methodology that makes a leader successful in team building, but their ability to navigate the balance between process and creative freedom. This balance is key to aligning everyone with certain expectations and ways of working, while also empowering teams to be flexible and work in the most efficient way to solve the problems at hand.
Wasting time on things that bring little value.
Let’s be honest; the very ambiguous story points bring zero value in the process. Using points that everyone can interpret differently, not only by teams but also by every single person, is just a waste of time. Yes, I know Scrum explains “the magic” behind relative the Story Points, but it doesn’t mean everybody agrees. This is usually promoted to measure “something” without a need to understand the complexity of what teams actually do. It’s comfortable; we like it when things are just simple.
I haven’t met anyone who said, “I love all these scrum meetings!” without sarcasm.
If you add some stupid ceremonies on top of that, you have a deadly combo. The sprint starts with 3–4 hours of planning (OMG, I experienced these mood killers), then at least 2 refinement meetings per week and, of course, standups daily with 10 engineers taking over half an hour each time (I’ve been there, too!). These things have to stop.
Transparency in teams is crucial, but there are better ways of doing it.
Building rapport between team members is critical. However, they won’t do it by breaking the ice with activities like throwing a ball on standups, forcing people to tell a “joke of the week”, or other cheesy activities. It’s not the time and place to do cringy stuff like that.
Planning (preperation) is everything
Scrum has a concept of a “refinement meeting,” which is an excellent way to address the exploration phase and build a shared understanding of the present and future projects. The problem is with the execution when these helpful meetings become a massive waste of time because most people who join them are not interested, irrelevant, or have nothing to say.
Plans are worthless, but planning is everything.
Encouraging everyone to participate in project exploration is crucial, but not by force. Those on the front lines often have the best insights into what’s feasible and how to achieve it, yet they are usually involved when it’s too late. When they’re separate from the discovery process, we risk setting unattainable deadlines and making unrealistic estimates, which can be detrimental to the project. Get the right people at the right time, and with enough effort, these highly unpredictable and unreliable guestimates become surprisingly accurate.
I’m eager to delve deeper into the product discovery & design process, but this topic deserves a dedicated post in the future.
Paint the future
You can’t have great engineering teams if they don’t understand where the company is going. Early visibility into projects, plans, and goals is crucial for teams to move forward efficiently. With the typical two-week Scrum cycles, people often forget about any work beyond the current sprint. The moment when it’s all about the sprint and conversations about why features haven’t been delivered on time again and spill over to the next one. The worst-performing companies are those where everybody is kept in the dark, and team members don’t know what they will be delivering in the near or far future. Roadmap reviews are necessary to help a company understand where the product is heading and how it’s evolving.
When good leaders communicate their plans, they open the door for significant change. They enable the team to challenge plans and allow them to have a conversation about the value and effort needed. Even the best project managers can get lost in their own bias and emotional attachment to specific outcomes, missing that some features or work is NOT that important and may be delayed, or scrapped. This means that anybody can challenge it, even that junior engineer in one of the teams, and potentially alter the course of the project for the better.
Well, it’s time to get shit done.
I like what Kanban brings, but many weird things don’t resonate. Scrum is far away from acceptable, too. The answer is always somewhere between. Whilst my typical approach won’t fix all the issues, it has always been a good template for me to start with and adjust to the team’s needs.
My primary concern with Scrum is its widespread adoption for the wrong reasons. Instead of being a set of ‘interesting and helpful guidelines,’ it has been elevated to the status of a bible, with zealous followers taking it to the extreme. This blind adherence has rendered it ineffective.
I challenge the stupidity and mindless push for “Scrum is the best”, and it’s time for companies to drop it and allow teams to do what they do the best — deliver. Without the red tape, without unnecessary bureaucracy and pointless rules that stifle creativity and team morale. Companies are paying 100k+ to bring talent on board and reduce them to code monkeys within their organisation. They become mindless followers of a Scrum religion enforced by those in power… How very life-like, right?
Ultimately, no methodology, be it Scrum or another, can resolve issues if leaders, at all levels, fail to take responsibility for their actions and genuinely care about their teams and peers.
Ps. Also Scrum is not agile 😊
