Is Your Software CM a Burden on Developers?
In a recent discussion on LinkedIn, “Is CM too costly?,” Dan George, a veteran software CM contributor, questioned whether or not "the CM process is too costly for the value delivered during development," eventually asking in regards to agile software development, "Is it simply unreasonable to think that CM departments can support fast paced work?"
I feel that CM needs to support agile methodology—and not just at a low cost. It is not enough to reduce the CM burden. CM must provide net value to the business and to the project. I'll even go one step further: There has to be a significant benefit to the developer and to every role on the project team.
You can't ask part of the team to pay for the benefits to another part of the team—that's not smart. There will some who just won't buy in. It has to be a win-win scenario.
The normal scenario has the project footing the bill for CM—tools, team, training, etc.—so that everyone can win. But after footing the bill, it's often the case that many team members don’t get net value from the solution. Key project members who represent each role must have a stake in setting tool requirements, and the requirements must aim high.
Low expectations and compromise during requirements specification often lead to first or second generation tools instead of 3G or 4G CM tools as I describe in my articles, “CM Generations - A Vision for the Future” and ”CM: The Next Generation of ALM.” Less capable tools can't support the process.
If you want CM to work, don't start with a 1G free tool. According to the History of Cellular Car Phones, the first cell phones cost more than $2,000 to purchase and install. The cell phones also came with high contract fees. Would you tell developers to use one now if it were free? 3G and 4G solutions are less costly than their 1G and 2G counterparts, and their capabilities go way beyond. They offer lower support and operating costs, more features, process support, more automation, ease of use, etc.
Don't burden your developers with 1G systems.
Tell your developers that you are going to:
- Simplify the code review process.
- Give them a single button or two so they know what problems and features they should work on next.
- Simplify branching, reducing the need to merge dramatically.
- Give developers a way to look at, promote, merge, and check-in entire changes so they don't have to do a file at a time.
- Give them a way to look at all of their work in the past year so they can prepare for a review.
- Let them go from a single line of code to a full explanation of why and when it was put there.
- Let them have everything they need for CM in one place and not force many days of training.
- Ask them what else they want in their tools and process, and listen to them!
Keep developers happy and keep every team member happy, including the product owners, testers, project managers, design managers, executives, and quality staff. Don't sit back on what you’ve been familiar with for years. Look at what's out there now—assess it and go forward.
How should you go forward? Read my CM Journal article: "Evaluating and Selecting CM/ALM Tools." Talk to your team and identify your issues. Bring CM vendors in (or virtually in) to tell you about their capabilities. Ask them how they can solve your issues. Familiarize yourself with capabilities through our CM Journal articles. Download and play with CM tools or read their concepts and overview documents.
Don't promise what you cannot deliver. Get help if you need it, and even if you don't, ask me or ask the social networks. Become a CM champion.
