Why Devs Struggle So Much With Methodology?
Is Not That Complicated, Right?
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
The world is already deep into Scrum practices. Some even argue that Scrum is out of fashion. I even read a great article by
stating that Kanban might be becoming mainstream (He really didn’t say that, I might be exaggerating a bit. Or a lot. Like in Lord of The Rings: “One Line to Rule Them All”. The link for his article is below, by the way). My point is, after years of working on project after project, with experienced developers, juniors fresh from universities, and building new teams from the ground up, with multiple nationalities and backgrounds, one thing is very common: it's rare to see a developer who truly understands methodology.
The good news is, with the age of AI, some Agile Coaches can sleep better knowing their jobs will never be replaced. No matter how many decades of Agile we get, there's always a need to teach the differences between the "Definition of Ready" and the "Definition of Done." But the question is, why?
Because Is the Manager’s Job.
Running a team or a project is the Manager’s role. The way that the project is executed is part of the job responsibilities. For that reason, it becomes natural that the Project Manager or any kind of Engineering Leads or Managers have some degree of practical knowledge of Scrum or any other Agile methodology. The Managers need a system in place that helps the team produce the work and have some type of metrics to follow the outcome’s pace and quality.
Project Managers (PMs) often have a strong bias towards methodologies, and they're usually the most knowledgeable about Agile practices in the room. For many experienced developers curious about methodology, becoming a Scrum Master is their first leadership experience. However, this role tends to be heavily focused on Scrum, which can limit their exposure to other leadership areas, particularly in overall project authority, communication, and stakeholder management. It's interesting to note that many Agile Coaches come from project management backgrounds, as it's a natural transition from a methodological perspective.
Software Development is Already Hard as It Is
Training a Software Developer takes years. It involves extensive study, both in academic settings and through real-world projects. It takes a lot to get a degree in IT, or being able to be onboarded on a new project and keep learning new technologies, different setups, and the pressure of maximizing deliveries. Software Development is a cycle of applied knowledge and the reason why Agile is so successful with its feedback loops. A Developer never stops learning and improving, even the most lazy ones.
One of the aspects I hated most about working in banking for so many years was that IT was seen as a 'geek silo'. I even witnessed cases of blatant lack of professional courtesy and arrogance directed towards IT. Someone with a typical degree in Finance or Business Management would struggle to complete the first year of an Engineering degree. It's not an easy degree to accomplish. There's a particular way of thinking that needs to be structured—to see and anticipate complex scenarios in a logical framework and translate them into code. This skill set requires time to master. Simply knowing how Scrum works doesn't pay a developer's bills; coding does.
The Majority of Devs Just Want To Complete Their Tasks
In a previous project, one of my star developers was sprinting toward the milestone. She was one of those people we could count on, especially in key projects with high visibility. The project in question was very sensitive; if we succeeded, we could open a new Service Offer, but if we failed, the entire plan could potentially be ruined. I told her, and she knew it—everybody knew—what was at stake.
In Kanban, there's this concept of 'Replenishment', where colleagues review a ticket and approve it as a team. However, she wasn't calling anyone for replenishment. Despite this, the tickets were moving through the board. So, I started asking questions and caught her red-handed: she was approving the tickets on her own, without any peer review. Was it a violation of the process? Yes. Was I upset? No. Because she had one mission: to deliver that critical piece of software, and nothing was going to stop her.
Developers primarily want to do their jobs, and certain methodological components may be sidelined when pressure mounts. Again, the methodology doesn’t pay the bills. Coding does.
Adding Agile to the CV is Enough
Because there are so many bad implementations on Scrum right and left, Agile experience often holds little relevance in developer interviews. In many cases, the interviewers themselves may lack a deep understanding of Agile. However, when screening for CVs, they need to have a keyword match, and in the IT world, the right combination of keywords is crucial for opening doors to new opportunities. While coding challenges dominate recruitment processes, it's unlikely a developer would be rejected for misdefining an Epic. Coding is the hard skill that truly matters. Yet, the industry has created a system where CVs must include 'flavor text' with a methodology of choice.
Devs Are Not Out of the Woods
This article might be cutting some slack from the Developers community about the lack of knowledge on Agile methodologies. While understandable, everyone should adhere to the project's established norms and working practices. Methodological systems are in place for a reason: To help follow up outcomes. These procedures should be followed. This means there needs to be an Agile Coach within each of us, all the time.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message.
Cheers,
Artur
It is a good point to focus on delivering value instead of following the most efficient, best-of-practice process. I recommend Matt LeMay’s “High-Impact Product Teams”!
I might have said that 😉 Thanks for the mention!