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:
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?
This guide will introduce you to the world of Software Architecture!
This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.