Odd Socks Consulting - Lean - Agile - TOC

Agile punctuation marks

Warning: If you're the sort of person who likes things black-and-white, then you might find the deliberately oblique approach, below, horribly annoying.

When I talk to a team which is starting an agile software project I usually ask them where their project's two agile punctuation marks are. 

Their what? 

image.jpg

I'll start with the obvious one.

1.  Agile Exclamation Marks - !

Most "Agile Exclamation marks" happen when we ship stuff.  That's when the "potential improvements" we've been working on become live and real.

Bang!

Bang!

Bang!

These days we like projects to look like this: 

! ! !    !   ! ! !!!! 

rather than this:  

               ! 

That said, sometimes, for very sensible reasons, you've gotta do Big Bang shipments.  Even then, this:

 

         !      ! 

is better than this: 

               ! 

Most of us - especially if we're programmers (or, like me, programmers at heart) - start new projects by thinking about how we'll build stuff up, which is important but also narrow-focused.  By asking a team "where and when are the exclamation marks?" and "what's stopping us having more of them?" we're asking them to place themselves - temporarily, but at the most important stage of the project - into the shoes of their customers and take a top-down and benefits driven view.  It's disturbing how infrequently that happens.

2.  Agile Question Marks - ? 

"Agile Question marks" represent risks and uncertainty - things you don't know but wish you did.  

I hate to go all gloomy, but we IT folk are too optimistic and too focused on the stuff we're gonna build. The older and grumpier (and more accountable) I get, the more I'm interested in knowing what could go significantly wrong.  I want to unearth those potential problems early, if I can.

What are the significant question marks?  Things like "that messaging system is scary, I wonder if it'll work out of the box?", "the vendor says they'll deliver in August but I doubt that, what's their track record like?", "we just don't know if people will buy this thing when we launch, will they?", "we don't know if our (internal) customer will have enough time to work with us, will they? What should we do if they don't?".

Significant question marks are the bits of the project that might kill us, or might not, we just don't know.  I don't mind little question marks - sorting them is our day job - but I hate the big question marks - especially when they're unsurfaced, unnamed or unmanaged.  I particularly don't like it when teams cross their fingers. That's not their job.

So, when I meet teams, I put on my daft laddy face (i.e. socratic face) and ask "where are your project's question marks?" and then I ramble on a bit about what I mean by that. Often, I'll conduct a quick pre-mortem, asking the team to "imagine five years have passed, you're all sitting in a pub, reminiscing about how this project almost destroyed your careers ... what was it that went wrong?", then I'll sit back and listen as the the big question marks pour out.  The stuff that comes out is often a surprise - even when the PM actively manages a risk register - and it's often stuff that almost every agrees on.

Just by naming the question marks, the team inevitably starts discussing them and thinking about how to remove them, reduce them, or, at the very least, put a font-size on them. 

clarke chingComment