Wednesday, 20 June 2012

A true story about my colleagues Olivia and Bob. Not their real names.

We launched a new website yesterday. It's a huge improvement on its predecessor in every way - congratulations everyone involved! Olivia noticed that the homepage inadvertently promoted a problematic message about the organisation's aspirations and views on ethnic diversity (sadly it's accurate about our success tackling internal diversity issues). She sent the site's senior editor, Bob, an email outlining her concerns. Bob invited Olivia round for a chat.

Whereupon he subjected her to a tantrum pressurising her to recant. "The tail wagging the dog" is the most printable part of his tirade.

My point here is not that Olivia was right (she was). It's that in the face of immense pressure she stuck to her point calmly, firmly, politely and consistently. She was exemplary, and it clearly took an emotional toll.

So yesterday Olivia, for genuine integrity and courage, you were my hero. Thankyou.

Tuesday, 19 June 2012

Hey why do engineers get all the fun!

Back when I was an engineer I learnt to pair programme. Now I'm a project manager, I don't pair any more.

Let's recap some of the benefits of pair programming:

Sharing knowledge - anyone can work in any part of the project

Sharing experience - everyone becomes a better coder

Acting as one anothers' conscience - ensuring that the tests (or specs) are written first, the code is properly factored, and whatever other tasks a programmer might be tempted to slide under the carpet

Working together is more fun than working on your own!

I think all this works for PMs too:

Sharing knowledge - everyone understands each others' projects and the broader business context, and can switch project if necessary

Sharing experience - everyone becomes a better PM

Acting as one anothers' conscience - ensuring that the release management has been considered, the training needs have been addressed, and whatever other tasks a PM might be tempted to slide under the carpet

Working together is still more fun than working on your own!

I don't care whether you call yourself a PM, a TPM or a Scrum Master, and which breed of Agile, Waterfall or anything else you apply. Learning from each other can only be a good thing.

So what am I doing about it?

So later this week I'm running a Pair-PM session. We're not going to shadow each other and we're not going to play chicken at each others' Scrums (though I think that would be a great next step).

We're going to get together, pair off and just chat about our projects. What's going great? What's vexing us? Where could we do with another brain? It doesn't matter if a novice pairs with a past-master and much of the learning's one-way - next time the past-master will pair with someone else. And we'll be breaking out of our usual boxes and hierarchies.

Monday, 11 June 2012

Since the end of 2011 I've been working on the business' internal product for online learning. Our portfolio of about 170 courses has a range of well-understood problems, and some less well-understood difficulties and aspirations. I was brought on board to deliver a new set of tools to author and and publish courses. It's a fantastic role, with a huge amount of trust and autonomy from my management, and involving me in Product Management almost as much as Project Management.

Near the start of the year, my Product Manager and Senior Stakeholder asked me to arrange user testing of the existing product, to find out what users thought were its best and worst points.

My previous experience of user testing hadn't been brilliant. It was run by an agency's lead designer with a highly suggestive questioning style, and it resolved a disagreement about site navigation between the client and the agency. So this time round I told my managers they they should have the courage of their convictions and specify the product that they believed in.

I was dead wrong. User testing turned out to be a fantastic experience, full of lessons for the project and for me.

In about 10 years of publishing online courses we'd simply never asked our users what they thought. We'd user-tested individual courses in development, but never the portfolio as a whole. So even if everything our users said had been entirely expected (it wasn't), their feedback would have moved us from specification based on gut feeling and sentiment to known user requirements.

Lessons for the project? Loads - not least the fact that our content specialists and technical specialists, whose aspirations sometimes seem to be at odds, are both right in their own domains. It's nice to find out that we all know our own fields! Beyond that, there are dozens of points to extract from the report and we'll end up with a much better product because of it.

Lessons for me? User testing can be a really valuable investment of time and money, provided you're in a position to be as receptive to criticism as you are to praise. Of course that's a matter of mindset and leadership, and of planning and execution.

Who am I?

Agile practitioner for twelve years. Scrum Master and Agile Project Manager (yes they do exist!) and now Delivery Manager for a decade.

Why am I committed to Agile methods? Because they treat grown-ups with respect. Clients who can legitimately develop their ideas and change their their mind. Teams who bring more to the party than ‘mere’ technical skill. Agile approaches both assume and foster fruitful collaboration.

I’ve been lucky to work with some really varied companies. I've seen different approaches to Agile delivery - some done well, some done terribly - and been able to gain broad experience. This blog represents some of that accumulated experience. Expect my opinions to change as I continue to grow and learn!

The by-line photo is nicked from a friend at the Cheap Emotional Response Network. You know who you are - thanks mate!