This weeks Hanselminutes was a discussion with Tom and Mary Poppendieck on Lean Software Development and what is "software success". Much of this discussion struck a chord with me and that I figured it would be good for me to drop a few thoughts onto my blog.
The initial part of the discussion started out with talk on what is the definition of “success” of a software project. Scott apparently was chastised by Mary on a panel for mentioning that he thought it was to “be on time, in scope, and on budget.” Mary stated that this is the definition of success according to “The Standish Group”’s chaos report, which measures software success on these criteria, and more specifically, failure of projects by not achieving these.
She then said that she feels that this is not an adequate (or even correct) measure of success, and that for a software project to be a success it must be a business success, not a technical success. This means that the software that is being implemented must create something that does what the business needs, such as achieving market share or being profitable, not simply accomplishing some type of task or goal.
I consider this to be a very important statement. I’ve been on many projects that have been completed on time, on budget and in scope. But they were never used. Or used briefly, and then forgotten. These, in essence, wasted all of the money put into the implementation. These types of solutions have always been in my mind to not be successful software projects even though many call them successful. Needless to say I don’t really like these types of projects, as in the long run I haven’t contributed to bettering the bottom line.
This leads to the idea that developers should not be measured by being done “by a certain date”, or on a certain “budget”. Mary stated that when she was at 3M that the teams that she was on had to show P&L for the projects, marketing plans, …, to be responsible for all that, and in short showing that profit would be made from the project. Or else, the project would not even be approved. I agree with this whole heartedly, and more organizations should really learn to do more effective forecasting of the ROI / IRR on software projects before jumping in to that pool and building away. Additionally, these measurements should also be used to guide the project alongs its path.
Mary then got onto a point that I think is very important, that her teams were held accountable to be responsible at a higher level than just time and budget, which are the typical things for which most software teams and project managers are held accountable. These teams should be held accountable for creating things that address a tangible business need. Their success must be measured on the actual problem solution, the successful capture of a financial opportunity by the organization.
One thing that comes to my mind, and that I feel she wants to say but never really gets around to it (probably due to time constraints), but I’ll say it (and I’ve said it to other before), is that it is my opinion that software is just a tool of implementation towards a completion of a solution / product. Software development is a tool in building things that allow businesses to exploit opportunities, and the focus of software development must be to effectively address increasing profit in an organization, otherwise the criteria for success of the project is incorrect.
Software development to me is not different than, say, using plastics in injection molding of car parts, or the assembly of those parts into a car, or any type of widget. If the widget is not something that anyone will buy (that is, it will make money, and money above the cost of building it), then it doesn’t matter if it is plastic or metal machinery, or software development, that put it together – it just shouldn’t have been done in the first place.
Where this discussion in the podcast was going, but never got to, was into discussion of product development, and what I would refer to as software product line engineering (SPLE). These higher level constructs for measurement that were mentioned by Mary, are in my opinion, components of proper product platform management, that uses software as the tool set for building the product, and where measuring success of products is in making profit (yes, I sound like a ferengi).
I'm going to follow up this post with another on my thoughts about SPLE as I think it is really important, but I need to address one more issue first. During this discussion, Scott made a mention about the agile technologies, and that don’t these solve all of these problems? Well, Mary had an interesting response which I totally agree with, and I’ll state it from my perspective:
Agile software technologies and tools as described today are an implementation detail of proper product management. They are the means by which you create the parts of a singular product made of software, not how you define what should be in your product, or as the parts used to build a suite of products. Measuring for success on using agile tools and methodologies alone is therefore an invalid measurement of the success of the products built with them.
I get a lot of flack from people I mention this to, especially at things like agile user groups. I don’t care if you use XP, Scrum, TDD, MDA, Nunit, Mocks, FitNess, … all that stuff … if you are not building the right thing, then all these just help you build the wrong thing better. Yes, they are important (and I do personally consider them to be very important), but they miss the overall target because the people working with them have myopic views of the overall organization since they are only in the trenches of software development. It's not their fault, but it is a situation that does need to be fixed.
Also, and perhaps more importantly, even if you are building the correct thing, but you are not building it in a way that can lead to greater agility in the future, then what is the purpose? This is something that touched on very briefly by Tom in the podcast, but could have used more elaboration as I think it is the real key to software success. Software must be built in a manner where it is used to accelerate future product development, so that the organization can become faster to market with products down the line. This is the holy grail of software reuse. Not using software necessarily to build software faster, but to use product components built with software to build products faster than competitors.
This last note leads again back into software product line engineering. I'll follow up with more on that topic in some future posts.