My chain of thought so far expressed in 4 books

In order of how the logic develops:

Managing the Design Factory, by Don Reinertsen

The Toyota Product Development System, by Morgan & Liker

Lean Software Development, by Mary & Tom Poppendieck

Flexible Product Development, by Preston Smith

Good words: Value

This post – and the last one - are an attempt at making more sense of a somewhat incoherent comment I made on Glen Alleman’s Herding Cats blog. 

I gave the background in my last post.  The second thought Glen’s post raised was re definitions of value.  Value is one of those words that has a different definition every time you look at it.  Glen seems to be basically arguing that the value (as determined by Earned Value or equivalent) delivered by incremental milestones under DoD processes is equivalent to the value delivered by iterative releases under Agile ones, in that they both provide “business value”. 

My take on that is that it’s true as far as it goes, but it assumes that there is no utility value in the intermediate deliverables.  In a lot of cases that’s true – it’s hard to see any partial implementation of an aircraft  flight control system being of much commercial use, for example.  But it’s not always the case.  For a lot of desktop applications a partial system can be useful once it reaches the stage of “better than what we’ve got now”, and that can happen pretty early in the piece, depending how crappy the existing system is.  If a business can be using the new one while you’re still developing it, they’re capturing extra value that they wouldn’t have got under a methdology that didn’t require early releases, whether you’re using EV or not.

I think where Glen was coming from though was information value - the value of confidence.  And that value is solid financial value – I think the Agile community is overly aggressive if they dismiss it completely.  Options have value, and more information gives you more options earlier.  Both EV milestones and Agile iterative releases support this by only counting deliverables when you can definitely say “yes, that’s done”, thus giving a more concrete indication to the customer of how close they are getting to having what they want, relative to how much they’ve spent on it.  Which neither a conventional but non-EV project or a highly-iterative project without intermediate releases achieves to the same extent. 

So yes, EV type approaches give business value incrementally,  but only if you’re prepared to define value differently from how agile does (which I am.  I prefer the lean approach – you don’t get to decide what constitutes value, your customer does).  And, of course, if you’re prepared to assume the plan is solid enough that it’ll withstand something coming out of left field – without that, progress against plan is meaningless, however well measured.  That one, I’m less prepared to take as a given.

Bad words: BDUF

This post – and the next one – are an attempt at making more sense of a somewhat incoherent comment I made on Glen Alleman’s Herding Cats blog.

Glen, who comes at the agile vs conventional discussion from a large-scale DoD/aerospace perspective, was arguing that modern DoD processes have incremental maturity milestones, which via earned value methods give early delivery of ”business value” equivalent to the agile concept of rapid cycles of “releasable” software.

All of which is good stuff – I don’t have any problem at all with phased processes for big projects, and for something that size you’d damn well better have some way of confirming along the way that you really are where you think you are – EV is a good approach to this. 

His post gave rise to a couple of thoughts which seemed worth sharing though, and the first of them is:

Don’t let the other side own the vocabulary

As soon as the other side of an argument gets to define the words, you’ve lost.  If X = Bad, where X is anything that looks even vaguely like what you’re advocating, then you’re reduced to saying “but my system isn’t X”.  Which is pretty much how Glen opens his post.  And that puts you on the defensive, and devalues whatever point it is you’re actually trying to make.

 And in this case, it’s unnecessary.  Firstly, BDUF=Bad is false.  There’s nothing inherently wrong with a BDUF approach.  The single plan-do loop has its place – in sufficiently predictable circumstances, it’s a highly efficient approach.  The problem has always been that “sufficiently predictable circumstances” are a rare beast – particularly in the software industry – and BDUF is applied in way too many circumstances.  But selecting an appropriate methodology is a management function.  If the wrong one is used, that’s a management failure, not a methodology one – even back in the 1970s, alternative approaches were available.  BDUF=Bad in this context is just a way of saying “Bad management decisons = Bad”, which isn’t something that needs a great deal of debate.

 Secondly, BDUF as the idealised agile bogeyman of absolute adherence to a linear plan isn’t even a good implementation of BDUF.  If you’re allowed to use variations on “if…then” and “repeat…until” in writing software, you’re allowed to use them in planning it.  Allow the planning part of a single-loop plan-do approach to have some risk management, contingency buffers, and iteration - all of which have been “conventional” project management staples since way back when - and you have an efficient and robust process which is effective across a reasonable range of projects.  Not all of them, by any means, but enough to make it a useful methodology.  So in this context, BDUF=Bad reduces to “Bad BDUF=Bad”, which again is true but not very useful.

Unfortunately, there are lots of bad high-level managers, and bad project managers out there.  So both “bad management=bad” and “bad BDUF=bad” provide plenty of examples to reinforce the “BDUF=Bad” argument.  But that doesn’t mean the conventional school needs to buy into it.  And if you don’t buy into BDUF=Bad, the argument then stops being about ‘is this approach BDUF” and can be purely about “does this approach work in its context, and why?  And more importantly, can any of it work in MY context“.  Which in my view is where it should be.

The Declaration of Interdependence

Ade Miller points to a summary of the APLN’s Project Management Declaration of Interdependence by Alastair Cockburn.

Thank you, thank you, thank you, Alastair.  The original is one of the drearier pieces of management-speak I’ve ever had the misfortune to read.  The summary is clear, simple, and effective.

Learning from the agilists

One of the reasons I’ve been poking around agile software practices recently is that I think the software community has a fair bit to teach the rest of the NPD world when it comes to flexibility*.  I would argue that the world is a more ambiguous place than most of the technical project based disciplines are prepared to acknowledge, and that our project management practices need to reflect that:  we need to learn to live with uncertainty rather than trying to squash it**.  The agilists came to that conclusion a long time ago, and have evolved some fairly powerful techniques for maximising flexibility and learning in a changing environment.  Although a lot of their techniques rely explicitly on the properties of software, that doesn’t mean they won’t translate to other fields, any more than lean approaches only work for automotive.

 I’m glad to see I’m not the only person thinking like that.  Preston G. Smith’s new book Flexible Product Development:  Building Agility for Changing Markets spends quite some time addressing this very issue.  I don’t think he takes some of it as far as it will go, but until I’m back in the commercial world I’m not going to have a chance to experiment with that.  Meantime though, it’s nice to have some of my thinking validated by someone with a rep in the field.

* The other reason is that I think that with increasing connectivity, and convergence of computers with portable electronics, chances are good that at some time in the not too distant future management of software development is going to become a core skill in the mechatronics domain.

** in fact I’m currently writing a paper which constructs a framework for arguing exactly this.

If Agile & Lean are the same….

OK, I’m no expert on either, but I’ve been poking round agile software development for the past few weeks, and it seems that the analogy between agile software development and lean manufacturing (or TPS if you prefer) is very close. Now I know that it’s hardly news that Agile fits pretty well under the larger Lean philosophies umbrella, but from what I can see most of the people making that connection are coming at it from a product development perspective, i.e. equating Agile to the TPDS.

There’s a whole philosophical argument to be had as to whether software development is “product development” or “manufacturing” – but for managerial purposes, creating software of sufficiently simple (or at least emergent) architecture that it can be created without an upfront design strikes me as closer to manufacture than to PD. And certainly it seems to me that the tools and philosophies of lean specifically as applied to manufacturing translate closely to those evolved quasi-independently for agile software.

So my question is, how come there isn’t more crosstalk between the manufacturing and software worlds? If they’ve independently come up with such closely related systems, there must be scope for each to learn from the other. But I can’t see many signs of it happening.