Scrum and Java projects. Why they tend to fail?
Scrum: The Love-Hate Relationship in Software Development
As a consultant, I've encountered countless clients who are passionate about Scrum:
"Scrum works very well!"
"Scrum sucks!"
"We partially (?!) adopt Scrum!"
Many believe Scrum is a methodology, but in reality, it's just a framework—much like Spring. Does Spring suck? Is it productive? Well, that depends on how you use it and how well you understand it. The same goes for every framework.
When Motivation Fades, Scrum Becomes Counterproductive
I've seen teams that were simply not motivated to use Scrum—or got bored after a few weeks. The daily 15-minute (or longer) stand-ups became a mindless routine, requiring only a generic update for everyone’s "greatest happiness":
"I worked on that feature. No blocking issues."
Meanwhile, during these meetings, people were:
- Typing away at their laptops 💻
- Eating breakfast 🥐
- Watching TV series (!?) 📺
- Scrolling the news on their smartphones 📱
- Chatting with their neighbors 🗣️
But hey, they were all definitely multitasking and listening attentively—right? 😏
The Notion of (Almost) Done
What about the definition of done?
Developer 1: "The task is done!"
Developer 2: "Cool! Update the Excel sheet. If we have time, someone will do a peer review."
Result? The task was kind of done, and the "peer review" was ultimately performed by the client—either on their validation system or, more excitingly, on their production environment. 🎉
Common Issues in Java Projects
1. Communication Between Developers
Many brilliant IT professionals are not great communicators. Scrum tries to help, but human nature is hard to change.
2. Constantly Changing Specifications
Users change requirements all the time. Most specifications are:
- Incomplete 📄
- Impossible to implement 🚧
- Vague at best 🤷♂️
Agile tries to help, but even with a Product Owner, changes are inevitable. Users are increasingly becoming client-oriented consultants, losing their domain expertise. Developers, on the other hand, need more business knowledge than ever before.
Invite a user to a technical meeting—you might be surprised at their newfound appreciation for your work! 😆
3. Time and Budget Constraints
A typical scenario:
- A sales guy sells a project with a wild guess at the cost.
- A random developer (not involved in the project) estimates effort: 100 ("It’s easy!").
- The project manager adds a 50% risk margin: 150 should be fine!
Reality? The initial estimate is almost always wrong. Agile assumes an endless timeline or a feature freeze—neither of which are realistic when clients are paying. Pure Agile is great for internal, continuous development, but in client projects? Not so much.
4. The Ever-Changing Tech Stack
New frameworks pop up every year, influencing projects for a brief period before vanishing. Some examples of once-popular but now-forgotten technologies:
- Flex
- Grails
- GWT
- ExtJS
- JSF
- AngularJS (1.x)
The result? A Frankenstein mix of old and new technologies glued together with duct tape.
5. Technical Skills vs. Actual Knowledge
Many developers know the syntax (Java, .NET, JavaScript), which qualifies them as "developers." But to build high-quality software, you need:
- Syntax 📜
- Grammar 📖
- Rhetoric 🎤
Without structured architecture and leadership, a project ends up being a mess—like five different authors writing separate chapters of the same book without coordination.
6. "All Developers Are Equal" Myth
Some Agile theories claim that developers will naturally find the best solution. In my experience? Not so much. The alpha personalities will dominate, and without leadership, everyone will work in silos, ignoring the bigger picture.
Code structure must be planned, and someone has to take charge. Otherwise, you end up with inconsistency, repetition, and spaghetti code.
7. Individuality Matters
Management often assumes all developers have equal skills and productivity:
"We’re late? Let’s add five more developers for two weeks! That should fix it!"
The Fordism of software development. 🚗
In reality, software teams are like sports teams:
- Some are excellent defenders but terrible strikers ⚽
- Some thrive in high-pressure situations, while others need structure 🏆
If you have Messi and Ronaldo, you’re lucky. But if Messi is playing as a goalkeeper and Ronaldo as a center-back… well… disaster awaits. 😅
Solutions?
"Okay, thanks for pointing out the problems! Do you have any practical solutions?"
Scrum is a generic framework—it can be used for Java projects, house-building, or even cooking a new recipe. 🏠🍳
But if we want higher-quality Java (or any language) projects, why not use a framework dedicated to that language?
"To increase the quality of our Java (or language X) project, why don’t we use a Java-oriented (or language X) dedicated framework?"
Let me know your thoughts in the comments! What’s your experience with Scrum and Agile in Java projects?