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?

Advertisements

Taking standardization too far

How far should you go?

There are ways to write software and ways to avoid.

As custom developers, my teams have written a lot of software.

Meanwhile, every time we bring new people on board, a question that comes to the forefront is “what is our way” to develop software.

Is it enough to say we are an agile shop, and XP happens to drive our flavor of agile more than SCRUM at this point?

What about the pieces of SCRUM we have appropriated as well?

What about the way we handle user experience, or document requirements, or resolve issues?

Being the same, being different

The more we follow “standard” methods, the easier new team members can join our teams, right? Couldn’t we just drop in a certified Scrum Master and all is well? (Well, not for an XP shop, I suppose.)

Meanwhile, the more we pick and choose what makes us most productive, the more we’re differentiated and the more we can produce competitive advantage through our processes, right?

I have been on too many methodology design projects, and I keep wondering why companies don’t just buy their methods like RUP, or just pick one and get a training company to have everybody start from the same page. (I know some do.)

My answer (to myself) is that though they would start with one way of doing things, they would soon be confronted with one of two options:

  1. Handle all sorts of exception cases and weaken the “standard approach”, or
  2. Even worse… they would cram all projects (and the people in them) into the same mold

From the same mold

George Dinwiddie’s weekend post on process standards triggered my thoughts in this area. It has also been triggered by the most embarrassing situation imaginable and my own rethinking of my offers to the market.

How does each person contribute to the team?

One of the most fundamental points in George’s post is that people have different strengths. They bring those strengths into a team environment.

In many cases it is difficult if not impossible to accurately distinguish the specific impact of each contribution to the team.

For example, the least productive developer is not always the one who completes the lowest number of story points in an iteration (e.g., if they invest in coaching and helping others).

The thing is, the more we use the same metrics for everyone, the more we insist on the same behaviors from everyone, the more we ask them indirectly to play outside of their strengths.

Meanwhile, removing them from the team could cut others’ productivity and ultimately risk project success.

In my comment to George, I mentioned three goals I had in identifying “our way” of doing things. Ultimately, they had to do with making it easy for people to fit into the team.

As I consider the potential negative side effects of removing individuality, I also wonder if too much standardization can be a trap, ultimately leading us away from the highly productive teams we are after???

Now, I could see how a very straightforward IT environment might do fine with highly standardized processes. It seems to me the more adaptive the environment, the more important playing to each team member’s strengths becomes.

So I have a specific question for you today – how much of my concern for individuality do you think relates to our work in custom software, and how much could apply to any situation?