One problem though is that the system can over time become out-dated, full of hundreds of bugs that no longer exist. Working on new features we may remove old code (and hence bugs) or fix bugs without knowing and the system isn’t updated. Time then has to be spent confirming each bug and removing them from the tracking system. You can in effect created work for yourself that won’t make you any money.

Arguably, if you have good enough reporting and feedback from your customers you shouldn’t need a bug tracking system. If something is really wrong, you’ll know and it’ll jump up the work queue as higher priority.

I don’t believe in fixing a bug when you find one. It should enter the work queue like any other piece of work. Software is written by humans so there will always be bugs. Just make sure you’re getting on with the piece of work that will benefit your customer (and in turn your business) most.

“Merging your code changes with someone else’s when there is a conflict slows down my development”, is a common complaint. In our case the number of developers is small and it isn’t as if they can’t work it out, it’s just that some see this as an impediment.

Branches in our organization tend to be very thin. All development is performed on the mainline (at the tip) builds are performed and tested from the mainline. Come time for release lockdown, one project group branches for release. The other group simply marks the branch with a label and moves on. If additional code changes are required a branch is created from the label. There is no intermingling between product groups so separate processing does not seem to cause concern to anyone other than myself who has to deal with both.

In our case the branch process is more influenced by the developers’ culture and acceptable practices than anything else.

Ron, I agree and would generalize your claim about the importance of management support: it’s critical to any initiative to improve, or even change. The organization. We who have given up the power to create have retained the power to destroy.

Agile (lean, etc) is a philosophy about software development that comes with tools and practices that may or may not be useful for a particular team.

The key to successful agile implementations (and I would welcome feedback from your “agilesta friends” is that if it works, almost always the “customer” or “business partner” buys into the value proposition (as does the team). If this is absent, its no wonder so may organizations fail.