Home » Software Development » Blind spot of software development methodologies

About Nenad Sabo

Nenad Sabo

Blind spot of software development methodologies

There is a trend of rise and fall of different software development methodologies. There is also a lot of discussion and excitement about which is better Agile or Waterfall or whatever, and what is Scrum really. My impression is that there is a trend of accepting processes and practices, with expectation that there will be always better results and fewer problems, which is not neccessary nor feasible.

Although I can see that some methodologies can have certain advantage over another when applied to a concrete software project + team + company, there is something missing. There are parts of software development which also can affect the success of a project or a team, or a company, but is not a methodology matter! I would like to think aloud about these simple things which somehow are underestimated, and are still very important:

Plain competence

You cannot have enough of this! Is it possible that you are oversteering our projects because your team is not competent enough? Just think about this: When was the last time anybody from your team picked up a technical book related to your project? Having a competent team will result in team members going for it, instead of looking for excuses.

Common sense team workflow

Does it make sense that whole team attends a meeting where most of the time couple of people have a discussion about how to implement something? Saying it is a scrum thing will not make it better, it is still a waste of time. I’m not saying that meetings are always bad, my point is that you should think about it if it works for your team. My suggestion is to let team decide on the workflow as much as possible, have them included. Also, having a process of “their own” can have benefits to team morale.

Every team is unique

My experience is that putting a group of people as a team will always produce results and processes which are unique to this team. If you force some sort of process onto them, sometimes you will get partial results, because team tends to work exactly the same as before, with additional overhead of being “compatible” with given process. Even if there is benefit, there is inertia to accept something “just because”. Team should have freedom to measure and accept practices which are working for them, and reject the ones which don’t.

As a conclusion I would ask a question: What other things in software development process do you think are important? What experiences from other teams can be applied to your team, and what certainly cannot because you are too different?

Reference: Blind spot of software development methodologies from our JCG partner Nenad Sabo at the Software thoughts blog.

(0 rating, 0 votes)
You need to be a registered member to rate this.
4 Comments Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy

Leave a Reply

2 Comment threads
2 Thread replies
Most reacted comment
Hottest comment thread
4 Comment authors
KennyMarvoSi JonesArndt Faulhaber Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

newest oldest most voted
Notify of
Arndt Faulhaber
Arndt Faulhaber

I agree!!! IMHO, in SE too much emphasis is put on the multitude of different approaches an methodologies, while the simple fact of us sw developers being normal human beings is (almost) completely phased out. E.g. we have our 15 min. biweekly standup meeting, which I do not feel comfortable with – in exchange for a “normal” weekly team meeting where one can sit relaxed and discuss/socialize some time. Ok, ich we just see the plain numbers here, you may have 1h per week replaced by 2 times 15 min. per week, but I think (at least for me) motivation… Read more »


If all that has happened as you adopt a methodology is that you have two weekly stand-up meetings, I can see why you’re not impressed.


Thanks for pointing out the fact that the human factor aspects are completely
ignored. Scrum is particularly notorious on this.

All attention is focused on the Burnt down chart!

Si Jones

IMHO, i think that there needs to be a slightly increased emphasis on how we are going to maintain / re-factor the output during the development process. Rushing / scrumming to the finish line is all well and good, but we know that we are storing up some debt doing that. Came across a variety of different research papers that suggested that if we did a good job of proper code comment (quality over quantity) and added some visualisations to the code then the maintenance task can be a lot more productive; and probably much less boring / frustrating!