Software Development

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.

Subscribe
Notify of
guest

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

4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Arndt Faulhaber
Arndt Faulhaber
12 years ago

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 »

Marvo
10 years ago

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
Kenny
10 years ago

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
10 years ago

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!

Back to top button