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

Every software development life cycle from Waterfall to Iterative to SCRUM begins with some form of requirements gathering or analysis phase.   There are lots of names for the requirements phase. Sometimes it is preceded by initiation or project planning phases, but most often it is the first phase of the SDLC. All of these initial phases typically have a focus on the product; its scope, features, architecture, quality attributes, etc. and possibly the resources, procedures, and tools to design, build, and test the product.

The missing and often forgotten activity in these early stages of the development cycle is what I like to call Stakeholder Analysis. While this effort could be considered part of an existing initial project planning or requirements gathering phase, I think this work needs to be called out as a separate phase in the SCM SDLC.   The focus of Stakeholder Analysis is external to the product; it is a focus on the surrounding environment or external aspects of the product. Who is going to use it? Who is going to buy it? Sell it?   Fund it? … and who is going to maintain the code base? This is completely different from the product-centric focus; and it’s only possible to develop awesome, complete, and clearly written requirements after understanding who is out there with a stake in our project.   An incomplete sampling of the stakeholders will lead to incomplete requirements. After all, they are the ones supplying the requirements – making this analysis a prerequisite to the requirements work.

Stakeholder Analysis => Requirements Gathering => High-level Design => …

Stakeholder Analysis belongs in SDLC. As business problems evolve over time, the software requirements need to evolve. What we seem to forget – unless we are calling it out as a separate phase – is to think about which stakeholder changes are happening over time. This activity is not only a periodical check to see if the the currently stakeholder needs have changed, but is also a check for new stakeholders to include. The list changes as business goals and sales targets change. Organization structure changes can also impact our list of project stakeholders.

The success of our projects is dependent upon a review of stakeholders included, regardless of which SDLC type we are following. Checking for changes to the list is an important thing to remember, and calling it out as a separate phase ensures that it will happen.

SCM is Stakeholder Analysis