Weeknoters block, Story boards & Process Maps, WIP and Estimates

Weeknoters Block

I’m struggling with writing weeknotes at the moment. Actually, that’s not entirely true. I write most of them, and then they languish in my drafts for a while. Somewhere between Friday and Monday I re-open the draft and start updating/editing it, only to have the process repeat itself.

In order to break this cycle, I’m going to cut the ever expanding content and paste it somewhere else, so that I can keep this weeknote small and break the procrastination cycle.

There’s a useful pattern here about keeping work small to minimise risk.

Story Boards & Process Maps

I learned recently that process maps are not always the best way of explaining how something works to other people. In the same way that you can look at a mindmap, but the meaning or context can be lost unless you’ve sat with the person whilst they created it.

Next time around I think I would go down the route of story boards in addition to process maps. This provides richer context and a narrative to hang better conversations upon, even if it’s communicated via stick men/women.

UXT075: Figure 5.16
An example of a storyboard. Buley, Leah. 2013. The User Experience Team of One. New York: Rosenfeld Media…

WIP

Managing work in progress limits remain a challenge. But then, perhaps it’s supposed to be a constant tension?

Anyway, we’ve got lots to do and much of it has interdependencies. Finding ways to unbundle things is genuinely quite exciting because it means smaller units of work, less complexity, smaller bets and therefore less headwork about intended and unintended conseqeunces.

I think some of this is about how well (or not) I’ve been able to estimate the size/effort of work in order to know when the team is at risk of juggling too many simultaneous things. Which brings me on to…

Estimates

“When can we expect that to be done?”

Estimating effort is something I need to get better at… or perhaps I need to get better at recognising when estimates are not all that useful and be more explicit about it.

Case in point.. ‘fixing the plumbing’. The specific thorny problems lurking within legacy software wrapped up in multiple of years of business decisions can be difficult to spot up front. You know they are in there, but you can’t be totally sure how they’ll manifest themselves until you’re doing the work.

I hark back to Gareth Rees’s excellent post on ‘building to learn’..

A complex problem requires a series of probing steps and analysis of feedback to fumble your way towards the goal.

And so perhaps in this instance, this is not about trying to get better at estimating that which cannot be reasonably known at the outset, but instead setting harder time constraints around smaller units of work and relying on feedback loops to find a path toward the desired outcome.

Knowing and being clear about what environment you’re operating within helps shape the right response. (I say this more as a reminder to myself than anyone else!)

Cynefin - vige.png

I’ve been reading…

Leave a Reply

Your email address will not be published. Required fields are marked *