 Lean CM is the process of doing the minimum CM to support development of a product. Of course this can result in less than optimum returns. Agile CM is the ability to adapt CM to the specific needs of an organization or project. There's a big difference here. Anyone who thinks that Agile Development implies minimal CM is probably in the situation of not having to deal with customers. Instead, Agile Development requires Agile CM, Configuration Management tuned to the Agile Development shop and philosophy.
Agile Development/CM does not imply, for example, that we don't gather requirements. It implies that we gather them in a different way. We still need to know what to build and we still need to identify what was built. The difference is that we don't specify all of the requirements up front. At first glance, this one example might make Agile CM look more complex! We don't "do requiremets" all at once with a small team. With Agile Development requirements may be constantly changing - there's no single spec for the team to work from. So this does sound more complex.
But take a look at the Agile process, understand it, and tune your CM to it, and things take on a different tune.
For one thing, because Agile is very incremental in nature, from a development viewpoint, it is more task-oriented than requirement-oriented, at least in a formal sense. However, when you dig deeper and look back through your Agile project, you find that the task definitions actually more closely match the customer requirements, moreso than a requirements specification which is usually out-of-date by the time it's released. The traditional requirements specification does not benefit from feedback during development to help better understand and define requirements. It doesn't adapt easily to market changes, and especially to competitive pressures.
Many argue that at least a requirements spec gives a clear statement of what is being produced, allowing better testing, product documentation, and so forth. If I'm building a launch vehicle for Mars, this may be very important. If I'm building a cell phone, my better tested, well documented product will simply fail in the market place because it targeted a market which has moved on to greener pastures.
Don't get me wrong. Having a clear statement of what is being produced is critical. What has to be different with Agile CM is how this clear statement comes into being. And in this case, CM becomes much, much more critical for Agile Development than for Traditional. Seems counter-intuitive at first glance. But consider that CM's main purpose is to manage change, and there's a lot more change happening when you're doing Agile Development.
So this is why Lean CM will never do in an Agile Development shop. Lean CM has a much better success rate with Traditional Development, precisely because change is less radical. An Agile shop needs to handle more change - and not just in specifications, but also in process. That's why we need Agile CM, that is, CM that can adapt to the changing process.
Task Definition: Gathering Agile Requirements
So how do we gather requirements in Agile Development? Well, first we have to ask the question: How do we know what to build? Then we have to ask the question: How do we tell the developers what to build? From the first question, we understand that we must first have a product concept, and a number of "story cards" or other representations of how the product is supposed to work. These are an essential part of the requirements. And the CM tool must support the management, including evolution, of both concepts and user stories.
But the whole point about Agile is that we'll discover requirements as we go - at the end of and beginning of each iteration. Here's where the Product Managers and/or Product Owners come into play. They are critical players in determining what the priorities are for the next iteration. So the important thing is how to communicate these priorities - these feature tasks - for each iteration. From a CM perspective, it's how to capture them. When we take the initial concept documents and user stories, and then add in the feature tasks, we have something that is very close to a requirements specification. We only need to make sure that the feature tasks are clear and concise, and then we need to identify re-works - how a feature as originally planned, has evolved differently.
Features can usually be easily gleaned from task specifications, often referred to as activities. Re-work is not as obvious. However, it again comes down to capturing the interaction at the end of each iteration. "We're going to move this from a pull-down to a pop-up menu because the customer finds it more handy there." Can we capture this as an issue, problem report, request or otherwise? The problem was expressed, and the resulting task defined. The real work is in capturing this statement, and then converting it into a problem report, or request, with a task defined which addresses it. How is this best done?
Generally, when reviewing progress at the end of an iteration, a series of requests are identified. Often solutions are suggested at the same time. It's a mistake to capture a suggested solution and turn it directly into an activity. There may be dozens of requests and we need to identify them, sit down and brainstorm on the solutions. In that way, we come up with a more consistent set of activities, better architecture and more team involvement. Capture the requests first and prioritize them. Review them and sort them into features (changes requiring new activities) and problems (changes to fall in line with existing activities). Create new activities and problem reports as necessary, and prioritize them. These are added to the existing product backlog. If a problem request is identified for a recently completed activity, it may even suffice to re-open that activity.
This sounds like it could be a lot of work - administration, forms, etc. Well, if it is, you're not using an Agile CM tool. To capture requests, you should be able to sit down with the customer and simply type in the request (maybe a title, some notes, and a priority) and hit an Add button, and then be ready to capture the next request. You might categorize them as problem or feature as you go, or use a single click to do so later. You should be able to right-click on each request and either generate a problem report, generate a (feature) activity, or relate it to and re-open an existing problem report or feature. Traceability should be automated so that the problem/feature activity is tied to the original request. If you have input from multiple customers, the request might be tied to an existing problem/feature if it already has been identified. If your CM/ALM tool can't make this process more efficient than having to use a spreadsheet, turf your tool. Don't use a spreadsheet.
Note the difference between requests (customer domain) and problems/feature activities (development domain). You are sure to get customer requests that require no software changes, the same or similar requests from multiple customers and requests that are not in the business plan. Don't muddle up your development domain by trying to keep all of these in one object class. Customers don't always know if it's a feature or a problem. Customers don't want to see the design details (generally). Each customer wants to be sure that you're tracking each of their requests. The development team just wants its marching orders. It doesn't have to be difficult to do, just Agile, with a good tool to ensure traceability and reporting capabilities. Ideally your CM tool should be a central focus of each "next iteration" meeting - whatever form or name it may take - and it should be capturing the results of those meetings, especially in terms of problem/activity prioritization and assignment, but also in terms of clarification. This will lessen the red tape and ensure that everyone, including testers, will have their marching orders clearly defined for the next iteration.
Doing all of this allows you to capture your requirements as you go, and in a way that facilitates the work of your team. Assigned problems/activities should appear on developer and tester to-do lists, and object-oriented behavior should be used to initiate (and trace) change based on those to-do list items. At the same time, the entire product backlog is captured and is there for the product manager/owner to consider for the following iteration.
Agile CM Basics - Keeping Agile CM Simple
Assuming your CM tool can handle the basic components of Request, Problem and Activity/Task, the next thing to consider are the more traditional CM capabilities.
The most important one is change packaging. At Neuma, we refer to change packages as Updates (see last month's article on terminology). An Update is traced to the authorization items (i.e. the approved problems/activities) and collects all of the files to be modified in a single place. The CM tool must facilitate the basic change operations. For example it should:
- Allow you to specify a Product and a Stream and/or Iteration for your context
- Automatically show your to-do lists for that context
- Allow you to create an Update which is automatically tied to your context
- Only allow creation of an Update through an object-oriented Problem/Activity action, and must automatically trace to that item.
- Associate, by default, each check-out operation with your current Update (with a selection pick list of any other active Updates you have)
- Allow check-in of the entire Update as a single operation
- Allow peer review (delta report) of the entire Update in a single operation (both before and after check-in)
- Allow promotion/roll-back of the entire Update as a single operation
- Allow developers to quickly assess the contents of their workspace
If you have these capabilities, you will be saving your developers time. CM will not be an overhead, but rather a productivity tool for them. Of course this takes for granted that they can easily navigate the source tree, that the delta reports are easy to read and adjust, that to-do lists are readily accessible, and that there's no other interference (such as artificial requirements to keep source code changes out of the repository, to manually apply labels, to branch unnecessarily, etc.). Take out any of the steps above and one of two things will happen: you will lose traceability information that requires manual effort downstream (or even by the developer), or you will require manual, error-prone data entry, navigation or repetitive overhead by the developer and/or others in order to capture information properly.
When you attempt to create "Lean CM" by leaving out capabilities, you create less "Agile CM" by forcing overhead elsewhere.
Build Automation
Agile projects are often associated with continuous builds. I'm fine with Agile projects having nightly builds, or twice a day builds. But whatever you choose, the key is automation. Build automation means first and foremost that, when it's time to do a build, it basically requires only a single button or trigger. Build automation can mean different things to different people. For example, does it mean:
- No manually maintained "make" (or "ant", etc.) files.
- Automatic selection of what goes into the build
- Tracking the difference between what is in the repository and what is to be built
- Generation of builds at different test levels
- Reporting errors back through an email or other alerting mechanism
- Automatic record keeping of the build content (i.e. how to reproduce it)
- Ability to generate builds for different variants and platforms
- Automatic sanity testing of the build
- Automatic build labeling, both in the repository and in the executables.
- Automatic generation of a list of updates, problems fixed, features addressed, etc.
I'm sure you can add to this list, and that you'll question some of these. What is not so important is that the build starts automatically each day or whenever a new Update is checked in. What is important is that, given the right parameters (e.g. Product, Stream, Promotion Level), everything else can be completed without human intervention. Some might argue: But what about sanity testing - that's not building? Others would respond: Why is seeing if an Update compiles more important than seeing if the Update "breaks the build"?
The next step is to give the developer the exact same automation capability (except, perhaps, without registering the build content in the CM repository). If the same process is followed, and even sanity testing completed, we'll have a lot more confidence in the Update.
Going the Extra Mile to Stay Agile
Once the basics are in place, there are a number of extra capabilities that help to make CM Agile. These are things that help eliminate the overhead while keeping the process where you want it. A few of these are detailed below. But making a process Agile is a continuous improvement process.
1. Requirements Tracking = Project Management
Traditional CM has Requirements Tracking as well as Project Management. Requirements are requirements, project plans are project plans. In Agile CM, these are not separate artifacts, nor separate processes. Your requirements are being gathered in terms of activities. You don't have two separate departments or managers - one for requirements and one for activities. Your product manager/owner is the project manager. What's different is that there is no schedule to lay out. Instead, it's a priority based project management. The highest priority items are addressed next. A loose bar is drawn to identify what's in the next iteration, but it's really driven by what's done by the next iteration meeting. Assignment of activities to development team members is still a task to be done in Agile because it's important for those with the most knowledge in an area to address change in those areas.
2. Allowing Multiple Updates Per Activity/Feature
Agile requires frequent iterations. Because of this, there are often activities which are not quite completed at the end of an iteration. In an ideal Agile environment, the mostly completed change is good enough to make it into the iteration, as long as there are no negative consequences, and there is value to adding it. If the tools aren't Agile, there may be an artificial tendency to either delay the change until the next iteration, or to redefine the task so that it matches what has been completed. This makes the Agile, less Agile - it requires additional overhead to deal with a common problem.
Sometimes, it's best to implement a feature across multiple iterations so that the initial hooks can first be put in place, or so that it may be implemented in an upward compatible manner. Whatever the reason, Agile CM must allow implementation of a feature through more than one Update. The Update itself is a container for each Change that can stand alone. The set of Updates for the Feature implement the feature. In our own shop at Neuma, we often use multiple Updates across a release development stream to implement a feature. It's important that your CM tool clearly distinguishes between the Update (Change Package) and the Feature (Activity/Task), and that it permits a series of changes for implementation of a feature.
3. Peer Reviews and Unit Testing
Even if you're using a buddy system, in fact, especially if you're using a buddy system, you've got to make peer reviews easy to do. Not one time per Update, but frequently during an Update as well. Good delta reports are the best way to keep on top of what is being done, and to review and re-review an Update. But if somebody's changing a dozen files, it can't be 12 times as much work to do the peer review. It's got to be easy to do. There are two parts: what you review, and your comments. Your CM tool should allow you to look at the entire set of changes in an Update with a single click or two. It should allow you to add context to the differences. It should use color to highlight the changes. And it should give you a choice of format, or even the choice of difference engines. It should also let you record comments, at least for formal reviews.
I don't mind reviewing someone's code if they simply give me an Update id, and from there I can do a one-click operation to see the changes, the activity description and even the test cases that have been tried. If I have to look at files individually, and then call up the activity description, and then look around somewhere for the unit test cases that the developer performed - well, it's not really too much, but it's certainly enough for me to put off doing it until I really have to. CM tools must make this whole process easy, and fast.
4. Automatic Update Generation
A developer makes the changes in his/her workspace, without doing any check-out operations. The changes work. Now what. Put it into the CM tool, says the team - but I've done my part of the work, says the developer. Whether or not you agree that changes can be done without first checking out files and tracking the Update to the reasons for the change, it's a fact of life that some people on your project are going to work that way.
An Agile CM tool could help if it could simply say: Press this button and I'll create the update for you - you can press a button to review it, and press another to check it in. Some CM tools allow precisely that - they will build an Update for you based on the differences between your repository context and your workspace. I recently talked with someone who had multiple typos trying to convert the workspace changes into a real Update that would be successfully checked in. With all of the long names, etc., it was taking hours with multiple tries. I recommended (s)he use a feature that would automatically create the Update, ready for review and checkin. It took a few minutes - and that person was happy. Agile CM removes all such overhead.
5. Minimize Branching
Some Agile teams mandate no branching. OK, I can live with that for a while. Why? Because branching typically implies merging and labelling. Merging implies identifying responsibility for the merge, and for the retesting that has to be done. Labelling means those labels have to be referenced somewhere to be useful. Perhaps it means modifying configuration view (i.e. context setting) scripts. Perhaps it means my builds won't be completely automated. OK. Branching can cause hiccups and overhead in an otherwise Agile shop.
Within a particular development stream, campaign, or whatever, it's nice not to have to do branching. But to do this requires two things: proper software architecture to minimize the need for branching, and good CM tools that help to minimize the need for branching. [I have no problem at all with, and in fact I recommend, branching for parallel development streams.]
Proper software architecture goes back to a few basics of software design: data hiding, doing things (like binding names) at run time rather than compile time, avoiding mega-files, etc. If there's contention on a file, there's usually a design technique that can be used to eliminate the contention.
CM tools can help if they support things like parallel checkouts without parallel branching, first order objects to identify builds, baselines, updates and the like, and promotion level management without have separate promotion level branches. The CM tool should always allow a check-in operation when the developer is ready - there should not be some artificial delay because it may "break the build" (poor promotion model), or because the "main" trunk is being switched over (poor trunk model). In mega-projects, and in small projects, I've rarely seen a problem with a simple branch-per-release-stream philosophy. And the benefits in terms of simplicity, automation and reduction in workload have been amazing, at least compared to some of the horror stories I've heard. I prefer having no (manual) labeling, no merge issues (other than on a parallel check-in), and no branching strategy documents and training.
An Agile CM environment really should minimize the need for branching.
6. Who Broke It
The Agile label has to go beyond initial feature creation. When you get to iteration 10 and find out that something created in iteration 6 no longer works and you want to know why, what do you do. This is where Agile CM comes in. We already have our CM tool which can do Build automation, including a capture of how to reproduce each build. From that information, a good CM tool should allow you to ask: What's changed between Iterations 6 and 10? If the tool gives you a complete source code delta, that's better than nothing. But perhaps it could give a list of updates - maybe there's 200 of them. A scan of the 200 titles might help to quickly isolate the culprit. If not, perhaps, retesting of Iteration 8 to see if its broken there could cut this number in half, and then in half again by identying the exact iteration where the feature broke. Now there's 50 updates - maybe you scan to find there are 10 candidate culprits. If the CM tool would allow you to select those 10 updates and bring up the delta reports for them in one operation , you are much more likely to zoom in on the problem quickly.
Summing Up
Some say, as long as the CM tool lets you do what you want, that's fine. But what I've noticed is that if the CM tool doesn't let you do something easily, the feature won't be used. If it doesn't do it quickly, it won't be used. If it's good and fast, users will discover new ways to use the feature. So performance and ease-of-use, in general, are extremely important to Agile Management.
There are numerous process improvements and CM tool features that can make CM more agile. Often such features become the highlight of a tool or process. It's important to understand tools intimately - and especially to understand how easy it is to streamline a process through customization of a tool. If it's difficult to customize, you may lose (i.e. spend, in resources) the cumulative benefit before it's even deployed. If you can do a click-customization or get the vendor to provide it for you, you're in a better position.
Also, Agile CM today is not what it was yesterday and not what it will be tomorrow. Yesterday's features are taken for granted today. It's the Next Generation of Agile CM that you have to be aiming at. And this means continuous improvement. So make sure your tools allow you to continuously improve without breaking the budget.
If you're trying to create an Agile CM environment by using Lean CM - you're headed in the wrong direction. All you're doing is spreading the problem to upstream and downstream groups. When you're serious about Agile Development, you'll find that Agile CM will be a core enabler. Agile CM is more demanding that traditional CM. But the good news is that Agile CM can be applied to Traditional CM. So as an Agile CM champion, you can make those traditionalists converts too!
A 20 Year Celebration
I didn't want to let the month of May go by without noting a significant milestone in the CM industry - the 20th Anniversary, this month, of Neuma, a pioneer in CM that evolved from the Telecommunication industry in Ottawa, Canada. Neuma is marking the anniversary with several announcements and the lastest release of it's ALM Suite: CM+ 7. When Neuma started out, there were few players, many now with different names: Aide-de-Camp, Atria ClearCase, Amplified Control, PVCS, CCC, Change Man and CMVC - not to mention SCCS and RCS. Neuma's CM+ went by the name STS back then. It was a tightly knit CM community, with regular industry conferences - usually as a working group add on to a larger conference.
Strangely enough, it was 20 years ago that Atria was founded, on top of the Apollo DSEE remains (who remembers that one?). Although there were some CM efforts prior to 1990, I consider 1990 as the real start of the commercial market for CM. Before that, most solutions were in-house, built on top of SCCS, RCS, or CMS (VMS). CM on Windows was almost unheard of prior to 1990. And in 1990, the CM user interface was the command line. Many developers, CM Managers and even CM tools, still cling to the CLI as the prime CM interface.
It will be interesting to see where CM will be in 20 years, and indeed, where Neuma will be. My congratulations and thanks to all former and current Neuma employees.
Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com
Trackback(0)
Comments 
Write comment
 |
CM: The Next Generation 
TrackBack URI for this entry
Subscribe to this comment's feed
