Development team transitions are a normal evolution of software development companies as they grow. The typical startup is organized like the surgeon’s model described by Fred Brooks in “The Mythical Man Month,” while enterprise software development is often structured in some kind of modular fashion.   The startup companies tend to employ more generalists; and the enterprise companies lean toward hiring specialists.   Understanding the necessary transitions from one to the other is essential to developing a good SCM program for your company.

One of the transitions a growing company needs to make is the introduction of development processes in place of the ad-hoc process.   These new processes are needed as the number of people working on the project increases, causing an exponential increase in the number of communication connections. Along with this comes an increasing number of new specialized disciplines adds as the enterprise software project is managed differently from the startup. These new specialists become new SCM stakeholders.

Most companies wait for problems before introducing process changes. This reactive approach is very tense and stressful at times as the needs of the new stakeholders come to the surface. In order for these reactive SCM organizations to become proactive, new stakeholders must be identified early and brought into the SCM requirements gathering phase.

Who are these stakeholders? Over the years, I’ve compiled a list of several stakeholder types to look for on your project. Some are obvious, while others may be new. Some will apply to your project, others won’t. The examples below are nothing more than a starting point for thinking about who might have recently come on board with new requirements for the SCM team.

• Developers need version control for understanding changes, and for working on multiple development branches.
• Quality Assurance needs defect tracking systems and the relationships between defects code changes.
• Legal teams need to know about third-party library software and how it is used or shipped with your product.
• Project Managers need to evaluate human and machine resource needs on projects.
• Program Managers need to evaluate the status of the development projects.
• Product Backlog Owners need to know when SCM activities are required.
• Escalation teams need to reproduce customer problems, and be able build and test fixes for previous releases.
• SCM teams need common, automated processes for managing builds and other common tasks.
• Backup and Recovery teams need to know important R&D asset locations, and the retention requirements.
• IT teams need to know which systems are the most critical to the R&D operations.
• Security teams need to know who should have access to confidential resources.
• Scrum Masters need to know that SCM resources are available for completing stories.
• Release Managers need to know if the requirements for release candidate builds have been met.
• Professional Services need to know where to find released builds for installation.
• Customer Support needs to know where to download hot fixes.

I like to think of this as a list of who I can help do their jobs better through automated SCM processes. I won’t be able to help everyone with all of their needs, so prioritization is necessary, but that is a topic for another day. SCM will always be included as one of our own stakeholders.

Timing of the process transition from wide-open, anything goes to controlled enterprise development needs to match the R&D stakeholder transitions. We can shift from reactive to predictive SCM transitions by observing changes in the stakeholder types and re-adjusting SCM process requirements accordingly. The change may be gradual, as is the case stand-alone company growth, or there may be rapid changes due to mergers and acquisitions.   Either way, there is a need for stakeholder analysis and feedback gathering over the life cycle of the organization. You simply cannot do SCM right if you don’t understand the transitions.

SCM is Stakeholder Transistions