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

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?

Unintentional “lies” in the software development field?

Beware the Chicken-a-saurus!

Marketing folks have learned a few things from software developers.

It is funny to me that developers often speak of marketing professionals as if they mainly lie to people about what they want to hear (or as if that were a moral thing).

I say that because it sometimes happens in our industry as well… maybe more often than we want to admit.

80% complete

I remember when I was just getting started in software… senior developers would report their tasks being 80% done… and remaining 80% done for weeks afterwards.

On better projects, they would report 80% complete on their first status report, and then 85%, 90%, etc.

And some of them couldn’t tell me what the “method of successive approximations” was. Go figure.

“Ready to ship” in 3 months

Or how about another example – that the software will be ready to ship in “N” months? In a recent MarketingProfs short, “How to Sift Through Unintentional Lies”, it cautions marketers to brace themselves for “one lie after another”.

It is worth reading, not so much to raise your hackles, but to learn about the perception we create in customers in whom we want to build an assessment of value. Though the article speaks about other domains than software, here is a fragment related to us, from their perspective:

No development team wants to miss a deadline—but it will happen. “There’s one project I’ve been watching that has literally been three months away from shipping for 18 months now,” notes Anthony. You’ll get more reliable estimates if you eschew a single, long development cycle for rapid cycles that produce a “minimal viable product” for testing and further augmentation.

[Bold emphasis mine. Again, please read the article at the source reference I included in the preceding lines.]

So there you have it… marketers asking for agile delivery of value. That’s pretty cool and a good place for us to work together on rebuilding trust.

Notice the article is careful to say the development team is not being malicious or intentionally deceitful.

I cannot remember a case where we have been, either. Most developers I know love to write software. We love to create and we love to solve puzzles… but let me highlight a third example before we close for the day.

Trusting each other

Now, there are explicit promises and implicit promises. In fact, it is the implicit promises that can do the most damage. You can try to disavow them easily or you may not even realize others think you made them in the first place.

In this case, DON'T read the manuals!

Have you ever made a promise to a teammate that you intended to keep, but failed in the end to keep? I know I have.

Did you ever “break the build” or overwrite someone else’s changes because of a merge conflict? I have done that, too.

Have you willingly taken on some task for a long time, and then just decided not to do it because it wasn’t really yours to do? Did anyone depend on it getting done, and did they know you stopped doing it?

Did you know you’d made a promise, or acknowledge the breakdown you produced? Not always, for me.

Do you think that failing to notice that you made a promise in the first place makes it any easier on the person you let down?

These are situations we create with our own teammates… and yet we sometimes try to diminish the importance of the cost we produce for others in failing to hold the promises we make.

Keeping promises requires professional attention

Many people write about agile methods being based on a notion of trust (including me). Quick releases, adaptive requirements, continuous integration, better testing and quick communication can go a long way to help us make and keep promises.

There are many levels in a project in which we make promises. They all count, especially in the eyes of those who accept our promises.

Keep the ones to your customers, but also keep the ones to your teammates.

Think about this – You may be committed to the top thing or two on your list, and everything else gets shifted around and de-prioritized. Though it makes you feel better to tell others you are over-committed, you may really be over-promising and failing to commit to the promises you make.

What hurts others also hurts your identity with them.