Configuration management (CM) or application lifecycle management (ALM)? Shouldn’t the focus really be on how you can improve your development lifecycle from an end-to-end perspective and break down the silos between analysts, developers, and testers? Does your team follow ALM principles? You could argue that every development team practices ALM when creating software products, whether or not they plan to do so. A given team will typically define its requirements and update them, split them up into developer tasks, then complete, build, test, and release them.
I believe the issue is not so much whether you’re doing ALM but rather how you’re doing it. For example, a pragmatic ALM approach in a small team of five or six developers might include a Word document or Wiki to capture requirements, a white board to track tasks, and an Excel sheet to keep track of test cases. However, things get more complicated as the team grows or the pace of development increases. For example, Dave hasn’t correctly copied his changes and has overwritten Paul’s changes. This is where version control comes into play. Then customers start asking for maintenance of the current release while work continues on the planned, new features. This sort of scale introduces the need for CM.
At this stage, a discussion about costs and benefits often starts to kick in. On one hand, CM might add some overhead to development, because it requires check out and check in steps. On the other hand, there are very tangible benefits from CM, such as the ability to retrieve a previous version, visual tools to identify a change (and its originator) that have caused a bug, or the ability to access the change history remotely—a useful CM feature if a particular developer or team isn’t immediately available.
When looking beyond pure development, CM usage is also found in other tasks, such as versioned requirements or test case documents— even if the CM is done by taking a new picture of the whiteboard or by changing the document name. Typically, there’s at least one place where requirements and test cases are held: in someone’s head, in a (shared) spreadsheet, or in a software tool.
The point is, in smaller teams with clear responsibilities and a shared location, it’s relatively easy to make all this information centralized and accessible for everyone. In this situation, information sharing is based on short face-to-face meetings and informal communication involving implicit or manual changes to each team member’s information stack. To get a holistic view, a team manager wouldn’t query a tool but would instead talk to his team members.
Bigger Teams, Wider Challenges
But as dev teams grow, the problems start to emerge. Specialization tends to creep in and information is less easily shared across functional boundaries. Questions such as What if the team genius falls sick? or What if two testers want to update the test case spreadsheet at the same time? can start to arise.
The immediate solution might be to address the pain points by implementing point solutions. Later, integration needs to take place to get an end-to-end view on project progress. However, teams don’t necessarily need to have twenty or more members to feel that need for more tool support. Such a need can start to rear its head when team members start to work remotely or near- and offshore teams are introduced. In these cases, just one person not being available onsite might make it worthwhile to think about effective ways to complement direct, face-to-face communication with a more robust CM approach.
The Value of Traceability
ALM as used in this article describes an integrated and coordinated effort to manage the software development lifecycle, as opposed to working with isolated solutions. Putting this transparency into the development lifecycle has already been stipulated in CM Crossroads a while ago. Adam Kolawa, to name but one, highlighted the following :
- Requirements must be properly considered and defined
- Requirements must be correlated to code and tests
- The impact of changes during maintenance must be better tracked
I won’t go into detail on points 1 and 3, but will focus on point 2. Eventually, a project manager will want to see what requirements there are for a given project, how the requirements relate to each other, what impact change requests might have with regards to code and tests, and what the project status is in real time.