Is there a methodology for axing methdologies?

Question

How do you garbage collect or eliminate outdated and cumbersome methodologies that are more detrimental than helpful to the software development process? How can you continually streamline your process to clear the way for programmers to actually get something accomplished instead of closing a thousand barn doors because of the escaped horses of yester-year?

Answer 1

In a word: communication. Between you and fellow team members, other stakeholders like project managers, etc.

The GC metaphor isn't pertinent; there's nothing external to your team that can rationally determine when a practice or methodology is eligible for extinction. That's a dynamic thing that has to be agreed upon by all stakeholders. It's a communication issue.

Answer 2

Humans are creatures of habit. Developers perhaps more than others.

Managers tend to want to try the latest buzzword-compliant tool/technique whereas their devs will want to stick with tried-and-true.

If you want developers to want to try new things, you either need to challenge them constantly, get classes for them, or somehow convince them that the manager-speak isn't what's important - it's the tool they should at least investigate.

You also need to make sure to listen to their complaints, and catalog them as technical or opinion.

If their complaints are mostly opinion, then maybe you need a different set of developers. If they're technical, then it doesn't matter how popular the tool is, it probably should be avoided in that setting.

Answer 3

I would use retrospectives to gather information on what works and what does not. You can use retrospectives at different points in your project cycle.

If you are using an iterative methodology, you should have a retrospective at the end of each iteration. If you are using waterfall, you should do a retrospective (some call it post-morten) once the product has been released.

During the retrospective, you need to collectively answer the following questions:

1. What worked well?
2. What should we start doing?
3. What should we stop doing?

Then, you can work with your team to prioritize what is important to them. Ask them what is the one thing they would like to change and start working on that one.