Jul 152011
 

I'm late, I'm late, for a very important date... no time to say "Hello" - "Goodbye"!

Over 90% of all projects finish late… according to one survey.

25% or more are delivered late… according to another.

Over 30% are late or over-budget… and so on.

We know what “late” means when it comes to software and IT projects, right?

…maybe not when it comes to Lean Software Development.

From XP to lean

By this point, if you are a frequent reader here you know that my thinking about agile development stems more from XP than SCRUM, though I have a pretty open interpretation of methods either way.

I also have an undergraduate minor in production and operations management, so Rafael Tolotti’s post a couple of weeks ago about his experiences on a Lean Software Development project triggered me to look more deeply into it.

I was especially interested in the notion of “deciding as late as possible”, #3 on Rafael’s list. So I followed his link (to Wikipedia, btw), which led me to other sites that had greater background.

Without adding too much history to this post (which you can find out as easily as I did), Tom and Mary Poppendieck literally “wrote the book” on the subject, so I am going to accept and refer you to their site as authoritative for the purposes of this post.

Anyway, the site speaks of this principle a little differently, as follows (currently under the heading “Learn Constantly”):

Last Responsible Moment
Learn as much as possible before making irreversible decisions. Don’t make decisions that will be expensive to change before their time – and don’t make them after their time!

[Incidentally, of the seven principles listed on Rafael’s Wikipedia reference, Poppendieck’s “Keep Getting Better” isn’t listed… it was apparently replaced by “deciding as late as possible”.]

It’s our responsibility

Sorry for the cheesy pics in this post... I was more concerned about the writing this time.

I have decided I like these distinctions, so of course I will adopt and adapt them in my use of life’s salad bar… while I continue to do some more research.

One thing I really like is the use of the word “responsible” above.

Responsibility requires that you accept being the cause of an outcome from the decisions that you make, for good or for bad. (Here I am not specifically speaking in a moral sense.)

If you decide too soon, without enough information, you might guess right – you are more likely to guess wrong – but you are responsible nevertheless. If you decide too late… well, you are responsible for that, too.

That, to me, is not the same as deciding “as late as possible”.

Rafael’s meaning

Still, it was Rafael that led me into this thinking. I am sincerely thankful to him for the gift of introducing me to new thinking, and I hope I do the same for you.

So let me make some interpretations about how Rafael’s assertion provided significant and powerful meaning for me.

As I think through all the projects I have worked on, there were some times we made decisions too late. Sometimes it appeared we made decisions at the right time.

But I think most of the bad decisions came with too little information and we might done been better by just waiting for a season.

I see two counter-arguments here:

  1. If pressure is to get to market quickly, we feel there is no time to decide… so we have to do it quickly
  2. If we have a concern for the foundation we build upon, we may want deeper insights and need to learn before deciding

But high throughput of business value is a key objective of agile development. So it makes sense that many agile projects lean toward #1 over #2 (no pun intended).

Given the cultural predisposition on an agile team to keep plowing ahead, I can see how the original principle of Last Responsible Moment could become “Deciding as late as possible”… and I can see how the latter might resonate better with a pragmatic team of developers.

Summary

So, how do I resolve all of this? I am going to use both, but keep up the knowledge of the powerful underlying distinction from its source.

As for you… do you see the different between “responsible” and “possible”? Put that way, maybe it seems more straightforward.

What do you think could be the real impact of one principle or the other on the way a team thinks and the way it works together? How might the different philosophies show up in the code?

  12 Responses to “What does “late as possible” have to do with writing software?”

  1. Hello Ken, excellent post. I really appreciate the deep analysis you did about the subject. I spread the post for my entire department.

    Other interesting thing about the subject was during this project using Lean Software Development, it was conducted a CMMI level 3 audit to check if the project was compliant with the model and process that the company was engaged and the rating was about 95%. One of the highest scores in the whole company!! So, for those who are afraid about Lean Software development x CMMI Model, don´t worry it´s possible and even more it’s enjoyable.

    Kind Regards.

    • Rafael, thanks for your comments. I am sensitive to creating the wrong impression when I refer to someone else’s post, so it is the greatest honor to me if they read what I wrote and comment on it as well.

      It is funny that you mention it, but I have also been reading more about CMMI certification relative to agile shops recently. Those who appear to have the most commanding knowledge of CMMI see no conflict in the domains and have provided some compelling insights for me. Meanwhile, many with an agile background but perhaps negative past experiences of heavyweight certification efforts are strongly against the idea.

      When an organization approaches CMM purely from a check-the-box-we’re-certified perspective, I think they are in trouble from the start… like many on the agile side who think “agile==no documentation at all”. They are equally starting from a shaky and unsupportable foundation.

      I will continue researching and thinking about this topic, because at its core I think every model is developed from a desire to make things better. I look forward to reading what you may write on the subject, too!

      –k

  2. Waiting until the last possible moment has a lot in-common with gold-plating. In both cases, development teams (including users and sponsors) make premature investments with insufficient knowledge.

    Certainly there are times when some decisions must be made, but like investing and gambling, there’s little need to do it all at once. In engineering, there’s no empirical evidence suggesting a “go big or go home” strategy has payoffs for developers or their customers.

    But even when decisions must be made earlier than we like there’s no reason to over-commit. There’s no reason to invest all at once. Even when it’s impossible to avoid the decision we can delay the investment.

    For instance, a project I once worked on needed a PDF library for manipulating documents. After reviewing a few we needed to select one to start development with. Not being experts in all the PDF libraries available at the time (there are hundreds) we picked one that covered most of the features we knew we’d need or suspected we might need and got going. We started with the trial version, extended the trial period with the vendor, implemented many of the features we needed until we came to an abrupt halt when the system failed performance tests (way too slow).

    Now that we had a mostly-working system, we had more information, more practical experience, and a new (specific) requirement we didn’t anticipate in the beginning but could challenge other vendors with. With the new requirements in-hand we found another library fairly quickly, negotiated another extended trial period, quickly implemented, and met our performance criteria.. until we discovered a limitation in the PDF specification itself. Another iteration, another another extension, and a little hand-coding around the problem and the final result met all the criteria for production.

    The coding was going to happen anyway, so there’s little need to work-out the present-net-value of it. However, not purchasing multiple server licenses for an expensive library saved a lot of money, gave us time to switch vendors, provided a better product, and increased our confidence in the final decision.

    So yes, waiting until the last possible moment pays off, but even when you can’t wait there’s still benefits to dollar-cost-averaging your decisions over as much time as possible.

    Rome wasn’t built in a day, and it wasn’t paid-for up-front either.

    • Tom, thanks for your observations.

      Your first paragraph makes it sound like perhaps you meant NOT waiting until the last possible moment is where people make premature investments with insufficient knowledge. So I am not sure if I track with how to reply to that…

      Either way, I accept the rest of what you wrote regarding Rafael’s (and Wikipedia’s) summary of this tenet of Lean. It reminds me of a book I am reading on the Korean War, during which time the notion started getting promoted that making any decision is better than no decision at all.

      In the software sense, we can learn fundamentally while we implement something specific… so making an early decision to use one framework or library increases our solution knowledge to an extent, even if we have to throw away the library in favor of a different one, as you had to. Shoot, in the case that the two libraries support the same interface or API, we might not even miss a step.

      Now, there is also the notion that one of the most powerful decisions we can make in some cases is to wait. Every decision is by definition situational, right?

      –k

  3. Every decision is by definition situational, right?

    Certainly!

    My first paragraph was only to introduce the idea that in cases when we can’t wait for /some/ decision one approach is to make the smallest decision necessary, and to make the least investment necessary into it so we may remain agile.

  4. From LinkedIn Group “Agile”:

    Valentin-Tudor Mocanu wrote “It is also a rule in chess or any similar game.
    In some cases , some managers are using for hiring PMs tests with seconds based decisions. I think that is a huge mistake… if you are not forced to decide quickly , you shall decide as late as possible.”

    …and Dave Myler wrote “It is always ‘possible’ to make decisions after the failure to make them earlier has started to cause problems. This is clearly not responsible, and in that respect I see ‘Deciding as late as possible’ as simply a mis-statement of the principle.

    “The principle is to try and maximise inputs to the decision process (by waiting longer), whilst not waiting so long that the lack of decision has undesirable impact. Deciding the right moment to decide is what we need to take responsibility for.

    “@Valentin-Tudor. I have to disagree with your statement that ‘if you are not forced to decide quickly, you shall decide as late as possible’.

    “It is entirely posisble to step back and take time to consider any decision. As late as possible in the extreme equates to never, so your statement suggests we either make snap decisions or no decisions at all. I would suggest that the vast majority of decisions fall somewhere in between, and that most (including during games of chess) are made at a point considered to be the most expedient.

    “Personally I strive to avoid snap decisions, but I won’t put them off indefinitely.”

    • Dave, I also thought it was a mis-statement of the principle. At the same time, it is powerful for me to consider how different interpretations of principles like “Last Responsible Moment” can affect how a team acts. If you go into one situation or another and simply assume people have the same interpretation as you do, miscommunications happen, as Valentin and I have been working through together lately.

      In the same way, Rafael (who wrote the initial post I referenced) had a great success on his project, and so the interpretation was effective for his team.

      Since we, in building, coaching and developing teams, enter into many arbitrary situations, we are sometimes thick-skinned and often called upon to be flexible, especially in welcoming new team members. We have to find ways to get to a common language so we can work together, accepting that sometimes these misinterpretations are not going to defeat our projects… but working toward better communication all the time.

      I like the way you summarized the intention of the Lean principle, “to try and maximise inputs to the decision process (by waiting longer), whilst not waiting so long that the lack of decision has undesirable impact”. That is great.

      And @Valentin, I can totally see your point. When I first read Rafael’s post, I thought to myself, “Wow! What a great way to look at it!” And then I started finding all the holes in that interpretation through past projects and [unfortunately] some current situations. That got me looking deeper into Lean, and I noticed that the Rafael’s team had based their tenets on Wikipedia, which had slightly misinterpreted them.

      So I think there is greater power in the underlying principle, but I can see how the slight misinterpretation that Rafael’s team had did not hurt them, I speculate because they had a coach and a vision for the product that could get them through the issues.

  5. On LinkedIn Group Agile, Jon Pearson wrote:

    The “last responsible moment” tenet is in direct contrast to a highly optimized solution. In order to truly optimize (squeeze every possible byte and usec out) all decisions must be locked in, because the more optimized the more fragile (== !agile). When a highly optimized solution is required, the last responsible moment to make the decisions may be before any significant code is written (especially if a hardware decision is involved, such as in a deeply embedded system). At the highest level, many individuals may believe the last possible moment to make key decisions like microcontroller choice is based upon delivery dates of the hardware and production line tooling (especially when a standard core is use and common among many verndors, like ARM Cotex-M3). Highlighting the timing of this “last responsible moment” can help the team and stakeholders realize when unreasonable decisions (can only use 16K of flash because it saves $0.05) limit the teams freedom to deliver the “optimal” solution.

    • Jon, right on. Thanks for your observations.

      When we have a highly optimised opportunity we are best to adopt a laser focus in our actions. You mentioned embedded systems as a great example – we cannot afford them to fail when life is at stake. Even if they are not that kind of device, we don’t want failures where we can’t quickly update the software.

      The distinction I brought forth in the post was related to responsibility, which supports your assertions just as well as those that might apply to other agile environments. When I hear a team re-interpret “last responsible moment” as “last possible moment”, especially as a way to defend an indecisive posture, I feel it critical to call out the distinction.

      To go to the opposite end of embedded systems and speak of human systems, there is support for just making a decision. Management circles often suggest that a bad decision can sometimes be better than no decision at all. I am careful not to lean too heavily on that tenet, but the key in either case comes back to “responsibility”… and how it leads to “accountability” (a different conversation).

  6. Also on LinkedIn Group Agile, Grant Rule wrote:

    Hi Ken, I agree, not many doing software development seem to understand this aspect of ‘developing in half the time’. But as has been said, it is all about generating know-how as quickly as possible so that decisions are well-informed and waste is avoided. The set-based approach doesn’t necessarily increase or decrease costs… its purpose is to reduce the ‘concept to consumption’ time, to minimise rework and risk.

    • Hi Grant. There are so many ways in coaching new teams that I come back to the elimination of rework. It really is a throughput killer, and to many people it justifies the waterfall philosophy to “know” requirements before writing your software. Ostensibly, if and when you can really know the answers, why wouldn’t you exploit that knowledge to write systems perfectly the first time?

      In the situation like @Jon’s above, embedded systems developers may “have” to know because their committed software cannot be as simply overwritten as, say, an HR portal or a Windows app.

      Of your three practices, which I accept in principle, the only one that strikes a little nerve for me is knowing *all* the solution options and rejecting only those that are not viable. (I suppose that is why you put it in asterisks.) Even so, when I reflect on it I can see many situations in my past where conversations of design produced such inventories, even if informally.

Leave a Reply