Home 
CM Journal Articles SCM metrics - a response.
CM Journal Articles SCM metrics - a response.
|
| It was a great pleasure
for us to discover that the March issue of the CM Journal was dedicated to SCM
metrics. We have been interested in SCM metrics for a long time and have worked
with them for the past couple of years. So it was with great interest and
curiosity that we read through the five papers in the issue. However, the more
we read, the more we realised that there are two - to us - very different
interpretations of "SCM metrics".
SCM Metrics - Metrics for SCM Traditionally, when people talk about metrics and SCM, they intend the role that SCM has in providing metrics data to others as laid out by the configuration status accounting activity. SCM delivers status information in reports to interested people throughout the organisation, pulling out raw data from the repository and formatting it - querying the version database. Other people use this status information to monitor processes and products that are important to them. It will tell them how things are progressing, alert them to potential problems before they become too serious - and help in establishing if that last improvement in process or product was really an improvement or not. As such, the status accounting activity of SCM is valuable for managing and improving processes and products in an organisation. However, SCM processes, products and tools also need to be kept an eye on and to be improved. That is why we believe that the SCM community should start to "look inwards" and not just service others with information for quality control and process improvement. SCM should also service itself with a range of metrics and benchmarks that can help the SCM people to manage and improve their own work. It would also help them justify the costs of the whole SCM organisation - not just the SCM people and their work, but also the work that others have to do when following the (sometimes hated) processes prescribed by SCM. In his Master's thesis [Borracci, 2005], Lorenzo Borracci made an attempt to come up with a complete return-on-investment model for SCM. He tried to identify the various costs and benefits and to put them into a formula that would calculate the return on investment in SCM. His main problem was that most of the parameters he found were either subjective and depending on the specific context or difficult to quantify and put a value on (or factor out from a more compound cost or benefit). That meant that the model became too abstract - or would have become far too detailed if carried through to the end - to be of practical use. The continuation of his work [Bendix et al, 2005] saw an apparent reduction in scope. The goal was no longer to establish a complete return-on-investment model for SCM, but more pragmatically to determine (a set of) single metrics specific for SCM and the tasks (tools, products and processes) that SCM is responsible for. The problems Borracci had to deal with in his original work, with the parameters that he termed partially- and non-measurable, disappear, as we no longer have to assign monetary units to the values. We simply measure a parameter and see how its value changes over time. So, as SCM people, our interest in metrics is just that. How can we use SCM metrics to manage and improve what we are responsible for - SCM processes, SCM products and SCM tools? From this "definition" of SCM metrics we will now go on to review the papers from last month's issue of the CM Journal, which we hope will make it more clear what we mean by "metrics for SCM". CM - The Next Generation of Metrics [Farah, 2007] This paper says very little specifically about SCM metrics (Farah did that in a previous paper, though), but focuses mainly on how we can become better at generating metrics - for others and for our own use. He points out that establishing metrics is not easy and gives general advice about what to do and what not to do. He mentions four important requirements to our environment to enable us to produce metrics with less effort. This is important as the less effort it takes to produce a metric, the more we can experiment - also with SCM metrics. So once we have figured out what question to ask, it is easy to ask it and to have some answers - or even to start with a few simple questions/metrics and let things develop from the results of that. One interesting requirement is that it should be possible to work with context views - such as when he wants to identify the problems fixed between the customer's existing release and the one that we are about to ship. Finally, he briefly mentions that the SCM process will demand traceability. As a consequence our tools must be able to handle traceability and must be able to collect data in a reliable manner. Metrics for Fun and Profit [Weatherall, 2007] Another paper whose goal is more to teach us about metrics in general than to talk specifically about SCM metrics. Weatherall states that as far as SCM goes there are basically three kinds of metrics: Control, Process and Analysis. We find that distinction very useful, but in our opinion it is not specific for SCM but is valid for other fields too. Most enlightening for us was to read about the Analysis metrics that are used to determine unforeseen trends or root causes. Such metrics cannot be planned but have to be explored - and for that we really need the "perfect" metrics environment sketched by Farah [Farah, 2007]. Again we do not feel that the examples given in the paper fit with our understanding of SCM metrics. We do not feel responsible for things like Defects per KLOC and Open versus Close Rates - others might be interested in that, but we do not see that as an SCM responsibility. The "products" that we are responsible for are things like build tools and merge tools. So interesting SCM metrics to us would be the number of merge conflicts (signalling a problem with the tool - or the development process) and the number of build failures (caused by other things than the code). Finally, a very interesting question, he asks us to think about, is what the difference is between collecting metrics and data mining. We have thought about that - and now we look forward to a coming paper where he treats that question in more detail (hopefully with many good examples of SCM metrics). Lean-based Metrics for Agile CM Environments [Appleton et al, 2007] We have followed the writings of Appleton, Berczuk and Cowham (and Konieczka earlier on) on SCM and agility with great interest, though it has not always been quite clear whether they intend to write about agile SCM or SCM for agile methods - maybe both. So we were looking forward to reading what they had to say about metrics, agility and SCM. They seem to take it for granted that "metrics are good", and take it from there in their quest for lean-based metrics. Ideally, they would have liked to measure the overall return-on-investment of SCM to the business. However, that measurement is too elusive, so in this paper they just look at how to measure aspects of SCM for their impact on the overall value-delivery system. In an agile context, metrics should measure both the performance and effectiveness of the value-delivering system, and how well we support the people collaborating in the project. We must look at how SCM can provide value to its "customers". In which way it impacts and supports the value-producing and value-delivering system. How SCM can show its "worth" by delivering business value to the latter and provide "flow" for the former. They identify the goal of SCM to be to ensure product integrity. For the front-end of the value-stream this means processes and tools for managing (change) requests. For the back-end of the value-stream it means processes and tools for establishing baselines and managing their integration and assembly. We would like to believe that there is also a "middle-end" that provides processes and tools to support the collaboration of a team of developers. To help their analysis of what to measure and how to use the results, they introduce a number of theories and concepts: takt-time, batch, lean, queueing theory, theory of constraints, "muda" (waste) and harmonic cadences. Much of this can be quite hard to understand and relate to SCM, but with a number of well-placed explanations and examples, they make it a little easier and less abstract. The place here is too short to list and review the examples. More generally, experience is also reported with version control related metrics. We find some of them (average commit granularity, average integration-test cycle time) to be only of marginal interest to SCM, whereas others (average number of files with merge conflicts per commit, average build-time for private builds) are definitely SCM specific metrics that could and should me measured. They observe that some metrics are relative, because we just want to observe some trends over time. Others are absolute and serve to give lower-bound, upper-bound and/or average values for the expected time for certain tasks. Such bounds could be used in relation with takt-time. For an 8-hour working day and 16 build requests in a day, the takt-time will be 30 minutes. If the lower-bound on build-time turns out to be more than 30 minutes, we will have to cut corners. Even though they are agilists, many of the examples they give of SCM metrics are generally applicable even in more traditional contexts. Like most agile people, they are "obsessed" with short cycles, which allow them frequent occasions of measurement - and intervention if needed. In a less agile context, we would have to spend a little extra effort to find "natural" points of frequent measurement. Finally, they often show how you can act on the results of their metrics, whether it be to maintain harmonic cadences or to spot concurrency contention. So in a way they have also provided arguments that "metrics are good". Is Your Metrics Database Write-Only? [Koch, 2007] Many metrics (databases) are write-only and are never actually used, which is just as harmful as having no metrics according to Kock. Metrics data are collected either because we can, because they were useful in the past, because we have a metrics program, or because others are collecting the same metrics. How do we do metrics in a more clever way so our metrics are also read and used? The answer is by using Goal-Question-Metrics (GQM), which Kock introduces in three small (maybe too small) steps. We have found GQM to be of help, but also a difficult method to use. Therefore, we would have liked to see a couple of concrete examples and in particular examples related to SCM - eg. if our product/goal is the release (process). It is not easy to find the right questions - and after that it "requires a bit of creativity and insight to turn the goals and questions into metrics". A list of SCM-specific goals and questions would be a great inspiration when we have to find SCM metrics that are relevant to us. Kock says that we should not collect metrics just because others are collecting them. However, a list of examples might make us realise that some of these goals and questions are also valid for us. This will make it easier for us to find the right metrics - and maybe benchmark and compare our results against others. The strong point of GQM is that it helps you tailor the metrics to your particular context and actual needs. However, this means that we must understand our own (SCM) organisation and its needs. For some parts the products from the SCM organisation are obvious and the goals should not be that difficult to find. The problematic part is the support and service processes that we render to others and that are only implicit in many cases. Here the goals, objectives, success criteria, or deliverables are not always so clear, which makes GQM difficult to use. What is it really that we are responsible for - and are we really responsible (i.e. having the authority to change it)? Once we can answer that, it becomes easier to use GQM - so how do we find the goals? We must understand our own (SCM) organization and its needs - but they are very varied [Borracci, 2005] - and that is the strong point of GQM, that it helps you to tailor the metrics to your particular context and actual needs. Metric Mania [Wagner, 2007] If you were not convinced before, that metrics in general is a good thing, this paper gives you another dose of good reasons for using metrics. Metrics are about change. "Willingness to respond to the data with changes in process, tool or personnel" - and we could add, that it is also about listening to what the data can tell you about changes that you have already made. Wagner also stresses that metrics can provide visibility into the root causes for the fires that SCM (or others) have to put out time and again. Just like Kock [Koch, 2007], he recommends that we start with the goals - what we are trying to achieve with the data. A project should define its goals and SCM should define goals for themselves as well. We would have liked a little more detail and examples of these goals, both for the goals of the project that will involve SCM and the "internal" goals of the SCM organization. We also would have liked to see some "benchmark" values for some example SCM metrics. Wagner states that a metric is only good when you can relate it to other data. In our opinion that is not limited to comparing with your own historic values, but should also include (relevant) comparisons with other companies to see how well you fare "globally". Summary It is very valuable that the March issue of the CM Journal has brought more focus on metrics for SCM. We are convinced that metrics are very useful also for SCM processes and tools - and have experienced how difficult it is to start finding and using SCM metrics. We see a need for improving our capability of providing others with useful and accurate metrics data (and to do so with as little effort as possible), but also a more pressing need to come up with a catalogue of metrics that can help us monitor and improve our own SCM processes and tools. The reviewed papers have helped us become better on metrics "theory" - but they still leave us somewhat in the dark as for how to translate that into "hard-core" SCM metrics. They mostly focus on general advice on how to approach metrics and how to become better at defining and using metrics (avoiding pitfalls). In most cases it is left as an exercise to the reader to figure out how to "cast" all this knowledge to an SCM-specific context. Another problem is that most of the examples in the papers are metrics that SCM can supply to the rest of the organization, but will not make us better at doing our business as SCM people. In reality the problem is that it is difficult to say what are the SCM processes, products and tools - and thus we cannot find metrics even with the help of GQM. Appleton et al [Appleton et al, 2007] gives most help in providing actual examples, but more can be done. We believe that giving "simple" examples of SCM metrics is not enough. Which metrics are "sensible" and which are not is highly dependent on the context. So we will need more descriptions and explanation of the problem, motivation, and pros and cons to allow us to choose wisely the metrics that we can use (some metrics are needed, others are "just" useful). Sort of a pattern language for speaking about SCM metrics - maybe someone wants to pick up that challenge in the future? Just as the reviewed papers, in our opinion, do not tell the whole truth about metrics for SCM, nor do our reviews tell the whole truth about the papers, so we strongly recommend that you look them up to get all the details if you are interested in (SCM) metrics and not already a (SCM) metrics expert. In next month's issue of the CM Journal, we will review more in general previous work done on SCM metrics - or metrics for SCM. Lars Bendix, Lund Institute of Technology, Sweden. Dag Ehnbom, Ulf Steen, ABB, Malmö, Sweden. References [Appleton et al, 2007]: Brad Appleton, Robert Cowham, Steve Berczuk: Lean-based Metrics for Agile CM Environments, CM Journal, March 2007. [Bendix et al, 2005]: Lars Bendix, Lorenzo Borracci: Towards a Suite of Software Configuration Management Metrics, in proceedings of the 12th International Workshop on Software Configuration Management, Lisbon, Portugal, September 5-6, 2005. [Borracci, 2005]: Lorenzo Borracci: A Return on Investment Model for Software Configuration Management, Master's Thesis, Department of Computer Science, Lund Institute of Technology, Sweden, May 2005. [Farah, 2007]: Joe Farah: CM - The Next Generation of Metrics, CM Journal, March 2007. [Koch, 2007]: Alan S. Koch: Is Your Metrics Database Write-Only?, CM Journal, March 2007. [Wagner, 2007]: Randy Wagner: Metric Mania, CM Journal, March 2007. [Weatherall, 2007]: Ben Weatherall: Metrics for Fun and Profit, CM Journal, March 2007.
Set as favorite
Bookmark
Email this
Hits: 8133 Trackback(0)Comments (3)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... Hi Brad! Your paper was by far the most useful - to us - and I hope that this is apparent from our paper. But still there are some of the metrics examples that you mention, that we (with our "special and restricted" definition) do not consider "metrics for SCM", but rather "metrics supplied by SCM". I subscribe to the thought of not trying to suboptimize, but rather look at the overall cycles. But once we have mapped out those cycles, we need to look at the pieces and the support they provide and in particular at what cost. If it is an SCM piece, it will become an SCM metric that has to be monitored and maybe "optimized" (or removed or "redesigned" if it creates waste). But still, our passion is SCM - not agile (at least in this context). So other people will have to take care of these overall cycles - and the non-SCM pieces of those cycles. So our focus is not on "how much effort has been used in *implementing* a single change" (which might be very important to others), but rather on "how much effort has been put into *handling* a single change" (as that is our responsibility as SCM people. Finally, you are perfectly right about your paper (starting by) assuming that metrics are necessary - we believe the same. The "mistake" was due to my "broken English". ---lars |
Brad Appleton
said:
 |
... Hi Lars (and Dag)! Actually, I would argue that the lean-based metrics in our paper from March due apply to the performance of the SCM process and tools. SCM process & tools usage/overhead is part of the overall cycle-time for several of those metrics (and codeline availability of the tools and the repositories and supporting infrastructure). Lean warns us about looking too much at the parts (suboptimization) rather than optimizing the whole. So looking first at the cycle-time of the value-stream that includes the tools process portions of SCM is the initial step to take before drilling down into which parts of the cycle are taking the most time and providing the most value (or simply creating waste). That is where the Lean concepts of value-stream mapping and waste-elimination enter the picture. If you start with the broader-spectrum cycle-time metric and follow the Lean principles, you will naturally "drill-down" into areas needing more investigation to see exactly where time/effort is being spent and which of those things are providing value. Also, I don't think the article starts off assuming metrics are "good" (they may be good, or bad, or both), but rather with the assumption that metrics are necessary in order to gauge "improvements." |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
