Part of managing software development is dealing with the challenges that arise. Delivering software requires overcoming the challenges, or at least mitigating the attendant risks during the development activity. Generally, organizations work with a constant level of challenge. When one challenge is overcome, the organization will take on a new challenge.
For example, when a project releases software that overcomes a technical challenge, it might then schedule a new release with a challenging timeline, or re-open the technical challenge by choosing a new target platform.
The next challenge is not "just like the last one, only more." An organization that successfully implements geographically distributed development does not follow up by adding another development office. The organization may well open another office, but doing so is now a normal operation; in order to maintain the level of challenge, some other "impossible task" must be undertaken.
While problems may have unique characteristics, there are a lot of common themes. This series discusses sixteen separate dimensions of challenge. The situation your team faces can be analyzed with respect to the dimensions listed here, and some appropriate conclusions drawn. Each dimension is dissected, and some approaches for dealing with it are provided. Here is the complete list:
- Human Language
- Knowledge Retention
- Location of Responsibility
- Organizational Structure
- Requirements or Business Demands
- Standards & Interfaces
- Simultaneous Development
- Technical Complexity
- Technological Diversity
This month the Journal is focusing on Release Management. Taken to the extreme, Release Management incorporates allof the challenges of CM but with less time to get things done. There's not enough time or enough room for me to write that article, so instead we'll look at two significant pieces of the puzzle: schedule, and technological diversity.
It's worth asking what Release Management actually means. If you check the job postings, you'll find a lot of open reqs for "Release Engineer" positions. Apparently, these folks are responsible for writing installation and packaging scripts. So a release manager would be someone who gave direction to release engineers. That direction, presumably, is release management.
So what kind of direction does a release manager provide? It includes determining the feature and update contents that go into a release, establishing the features and capabilities of the installation and deployment scripts, and monitoring the actual availability of complex features from development (to coordinate the application and installation components). Getting the right elements delivered at the right time-scheduling-is obviously an important part of release management. Other management-type functions, like bombarding team members with useless emails and scheduling far too many meetings, are basically constant and can be ignored.
There is an interesting difference in vocabulary between different kinds of software release processes. Some software gets integrated, while other software is installed. It seems that if a package is delivered in a non-working form, it is integrated into other, functioning, packages. If a package is delivered in working order, but requires some special operations to unpack it or connect it to the operating environment, it gets installed. And if the act of delivering the software is also supposed to make it ready for use, it gets deployed. There is clearly a distinction made between piecemeal delivery-with separate packaging and installation activities-and atomic deployment.
Technological Diversity- systems built atop multiple, varied technologies-is highly correlated with deployment rather than installation. This may be because diverse systems tend to have several contributing development teams, and because the natural modularity of the systems encourages the separate release of components. Because of this correlation, technologically diverse projects are a significant challenge for CM practitioners, and we will look at it here.
Scheduling is, of course, a part of project management. Nearly all projects have scheduling challenges, but most of them aren't configuration management challenges-so let's ignore those. Schedule challenges for configuration management lie in the areas of work breakdown, schedule estimation, feature management, simultaneous development and efficiency.
Work breakdown is the basic