Modeling the world in Post-It notes

A wall of story cards

Neon colors brighten rooms without windows... and make your eyes go buggy.

I decided to take a little break today and write something a little more on the creative and fun side.

I hope you don’t mind.

If you wanted one of my more serious posts, please jump here for another topic or come back tomorrow and enjoy the time I gave back to you today.

Here’s my creative context: I am working through some thinking practices as I deconstruct and reconstruct a client’s business domain.

A bazillion multi-colored Sharpies surround me, plus self-adhesive easel pads, colorful charts, spreadsheets, documents and process flows.

I love being surrounded by information and knowledge, and I love to sprawl. Bringing order to this kind of mess is the Great Puzzle we get to solve every day in IT, right?

(To be clear, when I say “mess”, I mean my war room, not my client. They know the truth!)

How could I ever run out of sticky notes?

But with all this joy surrounding me, I just realized I have no sticky notes (besides the ones on my laptop screen)… which reminded me of one of my newest Cyber-friends out in Australia, Alicia Dudek, and her post titled “Post-Its and the Real World”.

Alicia is pretty creative and though I have only known of her for a few weeks now, her creativity has a contagion to it that I really enjoy. Check her out if you are in that frame of mind. (If you got this far in my post, you just might be…)

So what’s the big deal about stickies?

I’m glad you asked.

When I first learned Extreme Programming, I learned about physical cards. I taught my teams using 4″x6″ cards, figuring they are big enough to see, hold and write on.

They are also more fun to tear up than 3″x5″ cards (which is a ceremony for my teams).

And then when I discovered office supply stores made them in all sorts of colors… including various neon shades, I was STOKED!!!

Story-tracking software

You know, I did use some story tracking software packages on a few projects… but I found that having the physical card was a visual clue to everyone on the team about how we were doing.

In addition, maintaining cards in software carries a fair amount of administrative burden… though it does produce nice reports and graphs.

But I was never a Post-It kinda guy. I rarely stick them anywhere… I just write on the top one, and maybe push it across my desk somewhere. More often, I complete the item or list and throw the sticky in the trash.

It looks like even Winston Churchill had stickies in his (real) war room... look on the back wall. Yes, I know they hadn't been invented yet.

So when I got to Alicia’s “Post-It post”, I realized how much stickies might be used in software development… and not just for site maps

Then I did a little research, and found out that more people use them than I thought:

  • I can see how their smaller form factor might keep your stories smaller.
  • I can see how requirements can’t get too big when your means of recording them is so small.

But how do you write on the back? What happens when the glue stops sticking?

I don’t think I am going to convert.

Oh, and now that I look… I seem to be low on 4″x6″ cards, too.

So this is something of a creative day off for my blog… soon I will write about Sprint holidays (but not yet).

If you got this far, you must have an opinion… stickies or cards? 3″x5″ or 4″x6″? Story software, or physical cards?

And why do you have a preference? There are no wrong answers, as far as I can imagine.

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.


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?