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.

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 two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

4 Responses to "Blind spot of software development methodologies"

  1. Arndt Faulhaber says:

    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 (and therefore productivity) would be higher if we returned to our “old ways”. The basic problem here is simply that there are currently no means to measure productivity quantitatively, as well as there is no simple/good way to measure competence.

    Still those are _the_ main aspects of getting things done.

    Cheers, Arndt

    • Marvo says:

      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.

    • Kenny says:

      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!

  2. Si Jones says:

    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!

Leave a Reply


+ three = 4



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close