Agile Management for software engineering is a tremendously interesting book. David Anderson tries to create an inventory model of software that will allow him to treat software as a manufacturing abstraction. He creates a flow model of value through the software transformation process. He follows a unit of inventory through the analysis/design/build/qa process. At each step of the process he knows how much inventory is queued at any stage and therefore the value held up there.
His purpose in doing this is to allow him to use the Theory of Constraints to optimise the production process. A consequence of doing this is to allow the creation of a financial model of the software process that can be communicated to executive management. Executive management understands notions of Investment and Operating Expense etc so he reasons that reporting the SDLC in this manner will help executives understand our black art. He's other purpose for this model is to undeniably prove that Agile methods provide value quicker than traditional methods.
The author bases these ideas on experiences he gained during his time with SprintPCS implementing projects using FDD methods. Interestingly, he now works at Microsoft with the MSF group.
Perhaps the greatest perspective shift the author encourages you to make is to drop your cost-accounting perspective and begin thinking about value-delivery. This is something that agile methods implicitly do with frequent delivery. He talks about Throughput Accounting as a model for measuring value held up in the system. Customers don't care how much of their money you've spent till now, they only care how much value you've delivered. This is something any project should measure. These ideas are related to the Earned Value concepts of traditional project management but the author gives it more emphasis and provides some ideas on how to measure value.
Overall, the book has some interesting ideas. The financial equations that are presented seem to, theoretically, have value. I think they have value more as models of the world rather than detailed accounting constructs. At times the equations are laborious and probably detract from the message being given, but now to the real critique;
Unit of Inventory
The author posits that a unit of inventory is a measure of client value that can be expressed in any format suitable for use by software developers. He sites Features from FDD, Use Cases in RUP, Function Points for structured methods and Story Points from Extreme Programming.
I'm not sure I agree with the author on this point. His position means that over time an enterprise will have many different sets of accounts. The applications developed using structured methods will have function point counts. The 80's RAD methods we tried in the early 90's will have some unidentified type of inventory unit, in the late 90's we'll have Use Cases and these days we'll have whatever your favourite flavour of agile is. What next?
The unit of inventory needs to be decoupled from method. It needs to be a pure expression of customer value. The customer does not care for your choice of workflow. Here it seems the author's lack of appreciation for function points really stands out. For some reason he feels it has something to do with Structured Methods, but it doesn't, it was never defined in that way.
Function points can be used as a normalization mechanism across any method, across any technology. Being method agnostic it's possible to use Function Points to measure the throughput of your own development group as well as any outsourced development. Allowing the executive to make better trade off decisions about "right-sourcing".
As I read further through the book and I really began to appreciate how critical it was to have a unit of inventory, it only further deepened my faith in Function Points.
Another critical aspect of an inventory measure, I feel, is that it needs to be able to be used over long periods of time. Applications can live for a long time and their inventory can go up and down over time as it's refined. From an application portfolio point of view it's extremely useful to have some inventory measure as it allows better decision making within this domain.
The last advantage Function Points have as the inventory unit is to do with granularity. Having worked in a RAD environment before which was "functionality-matrix" driven, the thing we always struggled with was the size of each function. For example, the function defined as "total the value of a sale" is quite different in size to "submit the EDI order to SAP". The Function Point value of these two "features" is significantly different to reflect the different granularity of the statement.
Risk
The book does not discuss risk in any material way, which is quite surprising because it's so focused on Investment. To me, investment and risk are two peas in a pod. The book defines Investment as any cost in acquiring ideas for the product to be developed, ie, the full requirements process. Which is fine, I have no real issue with it, except it doesn't work for all situations. But it doesn't try and value or measure risk. Surely a management method for Software must address risk in some fashion?
He does talk about the idea of requirements perishing, which is indeed a risk addressed by more agile methods, but it doesn't go far or deep enough for me.
Time Keeping
An undercurrent throughout the book that made me feel uncomfortable was the author's disregard for accurate time-keeping. In the situations he has worked in I can only surmise that he has had the total dedication of his staff and therefore has been able to average costs and not get into strife over this.
In the professional services business not keeping timesheets is a lot harder. Staff are added and removed from projects for many reasons, however much project leads don't like it. Different staff have different cost structures. A staff member may come onto the project for 2 days to resolve some difficult technical matter and then disappear to another project.
The very last sentence in the "Financial Metrics in FDD" chapter brings about the author's own demise in this area. To paraphrase, he basically says because a person can be working on different tasks in a single day that can be classed as Investment or Operating Expense it's critical to make sure they don't double count - hence timesheets.
In Conclusion
If you've read this far, I hope you can see that I've invested lots into this book. It's absolutely worth devouring. It's always going to be hard to write an ambitious book that crosses many domains without some shortcuts taken, or biases evidenced somewhere. Overall I'd recommend this book to anyone trying to understand the business of software production.
tags: function points agile management
