Bruce Lee and the Agile spectrum

I've been lucky enough to have practiced a range of the published Agile delivery methods: XP, Scrum, Kanban and now DSDM. And I've been doing this for 10 years now. Time enough to form some opinions.

Right now I feel that these techniques sit on a spectrum of Agility:

Winging it Too few controls Delivery at risk	more Agile <-----	Agile	-----> less Agile	Not agile Too many controls Delivery at risk
Co-hacking	Kanban	Scrum & XP	DSDM	Trad PM
Intimate communication Shared commitment Inexpensive Unconstrained Uncontrolled	Foster a Co-hacking-like work-style Owned externally to the delivery team 'Bottled lightning'		Agile-friendly governance Work-style-agnostic	PRINCE2 &c
	Focus on rapid delivery of highest priorities	Focus on inspect-and-adapt continuous improvement of product and team

Co-hacking

Hacking is a complex knit of ideas. Getting things done. Rapidly. Dirtily if necessary. On the one hand unconstrained sparks of genius. On the other, spikes that become rabbit holes and technical debt. Doing it your own way. No constraints, no controls.

At its best hacking is a beautiful sweet-spot for any creative professional. It's what Picasso did with his brilliantly innovative lithographs of bulls, an act of creative discovery without a known end-point. Co-hacking is simply my term for two or more practitioners working together - a pair of coders, throw in an IA etc. It sounds the team developing BBC Playlister worked this way.

Co-hackers have the Agile Manifesto almost down to a tee. Individuals and interactions - check. Working software - check (we hope). Responding to change - these guys can pivot on a dime. Customer collaboration? The customer's probably part of the team, so can't provide an independent steer. Even if there is an independent customer, she may not have much pull with the team

So as sweet as that spot is, co-hacking is not Agile. It's not controlled to deliver business value. But it is an important part of the spectrum.

Kanban

I was a Scrum practitioner when I first learnt of Kanban. It scared me. I understood the value of single piece flow. I appreciated the tremendous flexibility for the product owner in on-the-fly re-prioritising. But no fixed points? No obvious planning horizon? No opportunity to take stock? Challenging stuff!

Of course this places huge reliance and trust in an ongoing conversation between the customer and the team, and it engages the team to find their own feedback mechanisms. All this while letting the customer to re-prioritise at will.

So Kanban is perhaps unbeatably agile - more so than the rest of the spectrum.

More agile. Not necessarily better.

Scrum & XP

When I moved from XP to Scrum, they were already pretty similar. They've only got closer over time. Scrum teams routinely adopt XP technical practices - chiefly TDD but also pair programming. XP, which started with 3-month 'short' iterations, has converged on the Agile 2-week de facto standard, and has adopted retrospectives.

Scrum bills itself as a general-purpose Agile project technique suitable for all types of project, though you'll be hard-pressed to find it used outside the software industries. XP is explicitly intended for software delivery and includes technical practices. So it makes sense to consider XP a software-specific specialisation of Scrum (or vice versa - I don't mean to imply any precedence here).

Scrum & XP foster a co-hacking environment, with just enough governance to ensure that they keep delivering value. "Go make me some of these. Come back in 2 weeks to show me how well you've done." They're the 'bottled lightning' version of Co-hacking lightning, harnessing it to meet product goals.

And on the spectrum? They both provide time-limited iterations. Opportunities for the client to feed back and re-prioritise, and for the team to retrospect its own performance. For all the reasons that Kanban initially scared me, this structure provides a safety framework that is inherently a little less Agile.

Less agile. I didn't say worse.

DSDM

DSDM takes a very different approach to Agile. The other methods foster an Agile work-style with minimal governance, DSDM creates Agile-friendly governance but is agnostic about work-style.

Uniquely on the Agile spectrum, DSDM offers an up-front project timescale and cost. Just Enough Design Up Front and Timeboxes based on MoSCoW prioritisation (DSDM's approach to flexible scope) enable DSDM to offer the business a high-confidence timescale and cost, and fail-fast discovery if these are at risk.

Any responsible business considering a new project needs some confidence around cost and time to assess project value (Glen Alleman reiterates this point on his blog Herding Cats, and in doing so does us all a good turn). If you're offering software services as a third-party consultancy or agency, you'll definitely need some way to generate these figures.

But this confidence comes at a cost: a plan.

Yes there is still a Prioritised Requirements List (Backlog to the rest of you). Yes, the client still owns the priorities. But the very fact of having a project-length plan creates a resistance to changing that plan. Particularly the introduction of new high-priority capabilities, which will violate the plan. Then change control comes into play, something mercifully absent in the rest of the Agile spectrum.

So DSDM is distinctly less agile than Scrum, XP and Kanban. But not worse.

What about Bruce Lee?

Bruce Lee originally studied Wing Chun. By 1960 he was disillusioned with the artificial boundaries imposed by the martial schools so he founded a martial art philosophy: Jeet Kune Do.

I have not invented a "new style," composite, modified or otherwise that is set within distinct form as apart from "this" method or "that" method. On the contrary, I hope to free my followers from clinging to styles, patterns, or molds.

So you use the right tool or technique for the task. This kick exists in Kung Fu but not Karate? Use it anyway. You need a grapple from Hapkido? Go for it. It seems like the simplest wisdom.

Applying this view simply to the Agile spectrum: pick the methodology that best fits your project. Your customer has fluid requirements and a high level of engagement? Kanban may be just right for you. They need to know a cost and a date before they can commit funds? DSDM may be a better fit. Neither is inherently better and it doesn't matter which is more Agile - they're each a better fit in different cases.

Jeet Kune Do projects

The PM and/or Agile methodologies present themselves as 'whole'. XP is a great example, with a range of practices that support one another: unit tests, refactoring. If you don't employ them all, XP warns that you're heading for disaster (Matt Stephens entertainingly parodies this as a ring of poisonous snakes). Similarly with most methodologies, if you're not following enough of their directives you're not 'doing' Scrum/DSDM/whatever/delete as necessary. You're headed for the rocks.

This is good advice for neophyte Agile practitioners. Each methodology presents a coherent project delivery toolset. If you follow the teachings of a well-reputed school, you'll probably come out OK and start learning how it all fits together.

But this approach also encourages experienced practitioners to pick a school and stick to it. This is clearly nonsense - the existence of multiple successful Agile schools proves there's more than one way to skin a cat. Any given school is probably not a perfect fit for a given project situation, so we should expect more of the experienced practitioner.

Jeet Kune Do projects mix it up. Your client requires up-front commitment? Give them DSDM Foundations. They need an MVP in 3 weeks? Re-configure as a Scrum backlog and use some appropriate tool to track progress - burn-up perhaps. The team wants to operate with WIP limits. No problem. Minimum quality guarantees? Use a Definition-of-Done, or a defined Quality Level or Pair Programming or...

A JKD project practitioner makes herself aware of what the project needs from moment to moment. She knows the teachings of multiple Agile schools, of various Masters both great and small (Fowler, Keogh, Uncle Bob etc), perhaps even schools outside the Agile family (PRINCE2 et al). She understands what each tool gives her, which others support it and where to let go.

And one day, if I work hard, I'll be as good at Agile project delivery as she is.

Agile methods in Prussian military doctrine

The Agile Manifesto was written in 2001. Prussian military doctrine, developed in the early 19th century and refined between the 20th century's world wars, anticipated key elements of agile methods:

• Requirements as needs rather than instructions
• Devolved authority

It also anticipated large organisations' difficulty adopting genuinely agile approaches.

Bear with me here.

The history

In 1806 Napoleon defeated Prussia at the Battle of Jena-Auerstedt. Prussia became part of the French Empire until the formation of the Sixth Coalition in 1812, which finally defeated Napoleon. This led to a major rethink of Prussian military doctrine with two goals:

1. Institute a way to counter an individual genius like Napoleon
2. Punch above their weight when facing larger enemies

The new approach was dubbed Auftragstaktik - Mission tactics - by the old guard who preferred traditional command management.

There are dubious claims of Auftragstaktik's success at the battle of Königgrätz (1866). Germany certainly built their capability after the First World War and whatever else is true of them in the Second World War, they fielded an astonishingly successful military. Auftragstaktik was key to this success.

Auftragstaktik described

Over to Gerhard Muhm, a Colonel in the German campaign against the Allied advance through Italy.

From my first day as a student officer the expression "Auftrag wiederholen" ["Repeat the mission"] rang in my ears. Our superiors wanted us to "repeat the mission" that had been assigned us to be quite sure that we had understood it. And they always said "Auftrag" ["mission"] and not "Befehl" ["order"]
.
And so it was through the entire Italian campaign. I always was given an "Auftrag", never a "Befehl". And I always did the same with my subordinates to whom I always passed on the "Auftrag", in the well-worn traditional "Auftragstaktik" of the German Army.

The tactical concept followed by the German Army was the "Tactics of the Mission or Task" in contrast to the "Order-type Tactics" ["Befehlstaktik"] in use with other armies. The difference in conception and execution between these two tactics is fundamental: the first exalts the soldier's intelligence and capability, the second tends to damp them down, making the soldier a passive executor of the orders of others.With Auftragstaktik a mission is ordered and the officer is left with the freedom to carry out the mission assigned to him, and so he feels responsible for the actions which are suggested to him by his intelligence, his enterprise and his capabilities.

Similarities to agile methods

The similarities are startling:

• Tell the team what you want them to achieve, not how to do it
• Then let them use their experience and expertise to get on with it

There's another striking similarity: the communication of military intent. Auftragstaktik requires the communication not only of the substance of the mission but of its underlying purpose. To understand the intent of the Auftrag, German offices were trainied to operate two levels higher than their current rank. This typically led to short orders, clearly stated.

Compare with a Role/Action/Goal user story:

As a: General commanding the defense of Italy
I want: Your company to defend a line as far South as possible
So that: ...

What's the goal here? To slow the Allied advance? To halt it? To hold a specific city? I can only guess - thank God I'm not a German Colonel in that war and I'm not trained in strategy to the level of Major General. I need a well expressed Goal in my user story if I'm to meet my stakeholders' needs.

And there we have a powerful core of agile methods:

• Requirements as needs rather than instructions
• Devolved authority

Agile versus large organisations

I suggested that Auftragstaktik also anticipated large organisations' difficulty adopting genuinely agile approaches.

Modern English-speaking armies call Auftragstaktik "Mission Command". At this point I'll quote Wikipedia directly:

the British Army in 1987 announced an intention to adopt 'Mission Command', yet an internal 2004 British Army review of command and control in the Iraq War in 2003 clearly shows that they had achieved the reverse: British orders were substantially more detailed, and subordinates generally more constrained than twenty years earlier, indicating that there is more to Auftragstaktik than process.

In organisations with a culture or expectation of following orders, the freedom to implement either Auftragstaktik or agile project management is severely constrained.

Credit where it's due

This blog entry leans heavily on two sources:

• Wikipedia's page on Auftragstaktik
• Gerhard Muhm's memoir online

The comparison between Auftragstaktik and agile methods is mine.

e-Learning industry, get your act together!

I've lately had cause to examine e-Learning authoring tools on the market. I've found that the entire market - the e-Learning culture - is broken. It's stuck around the turn of the century, and badly needs to catch up to the lessons of the last decade.

Hey, chill out Guy! Are you really taking issue with the entire industry?

Well it’s not just me but kind of. Yeah.

A challenge for you

If you are of the e-Learning faithful, I expect none of my arguments below will persuade you. So here’s an uncomfortable fact about my own department, that I expect is true of yours too.

Our colleagues in the business come to us for online learning only when they have to. We have dozens and dozens of e-Learning modules, built to a very high standard of learning content and immersive interactivity. But the only ones that get high user numbers are the mandatory ones.

If this is true in your company, then there’s something wrong with the resources that you’re providing. The industry has sold you more and more ways to improve your content – PowerPoint conversion, synchronised narration, templates, enhanced interactions – and elective users stay away.

If I am wrong, if you organisation produces non-mandatory e-Learning modules that your colleagues proactively and enthusiastically seek out, then please get in touch. My boss will pay you for your secret sauce!

If not, then something is broken.

How did I get here?

I've been an internet professional for about six years now. I joined a large media corporation as a software engineer and gradually became a technical project manager. Turns out, this particular corporation puts a huge emphasis on things like information architecture and useability - I honestly believe that many of our engineers understand user experience better than a lot of user experience professionals out there.

A few of the things I've learnt:

• The site your users spend the most of their time on is somebody else’s, so your navigation and user interaction have to be simple and obvious, fitting the broadest best practice on the web

• Standards-compliant sites win - you want as many people as possible to use your site, right?

• Links and URLs are core elements of the web - sites that freely link to other sites provide a richer and more valuable experience for the user

• All the great sites respect these rule of the web - Google, Wikipedia, YouTube, Amazon - even (to a degree) Facebook

And of course...

• Content is King

e-Learning software - what do we need?

I'm hard at work in our e-Learning department, not commissioning or authoring courses, but devising an approach to update our course commissioning workflow and technology.

Back in June I blogged about some of the user research we commissioned. In the first part of this year, I also did a fair bit of research online into what the most effective learning material looks like. So I've recently been able to complete a vision document for the new product.

Next question: build-or-buy? Obviously it would be fun to build our own authoring tool, that does just exactly what we want. But if I'm honest, buying something off-the-shelf will be cheaper, much quicker and a great deal less risky. So lately I've investigated a large number of e-Learning authoring tools.

Oh dear.

Page-oriented or Slide-oriented

A few product features are available over and over again:

• Outputting a Flash presentation

• Converting from PowerPoint

• The ability to play on iPads and Android tablets through special software or...

• Playout on iPads and Androids with HTML5

These characteristics are common across almost all the authoring systems available, from niche players to the biggest names in e-Learning. Next to these, the features that distinguish one product from another are scarcely relevant (desktop vs cloud, stock photos of 'actors' with hundreds of poses and thousands of emotions, etc). This is the industry paradigm.

These features push what I call a slide-oriented view of e-Learning content.

• Page-oriented: Consecutive pieces of content in the course load as separate web pages

• Slide-oriented: Consecutive pieces of content load as consecutive slides in a player, within a single page

Page-oriented content is how the majority of the web works. All those web hero sites I mentioned earlier: Google, Wikipedia, YouTube, Amazon and Facebook. The top 10 websites in the US and in the UK work this way. That's a pretty strong recommendation.

Slide-oriented content is my description of content that emulates PowerPoint. I'm particularly concerned with e-Learning here, but it includes some other experience-based websites and even some corporate sites.

A deep-seated mindset

From my research online, and discussions with my e-Learning production colleagues, I think this reflects some deeply held beliefs in the e-Learning community:

• You have to control the user's learning journey - you can't allow them to visit any slide (or page) in any order.

• Keeping all your content within a slide container is somehow 'immersive' - re-loading a web page would break the spell.

• e-Learning content is not web content - it's something different, with different rules.

• PowerPoint is a really great model for online learning.

The first two of these are exploded by all the best websites out there. Think of any website you love - it allows you to browse from page to page, unconstrained. And those pages re-load in your web browser - they don't seamlessly re-load in some container within the page. (OK I'm sure someone will identify a determined exception.)

Why do you keep coming back? Because you can find what you want easily, go where you please, and because someone emailed you a great link to some really great content - just that little bit there that's really interesting/funny/relevant, not the start of a 10-minute presentation to wade through. Maybe it piqued your interest and you checked out the rest of the site. Maybe it didn't.

That's how the internet works. It's been pretty successful.

But e-Learning content isn't a website, and it follows different rules. Really? Here are the best and biggest e-Learning sites I know: Google, Wikipedia, YouTube, Khan Academy. All of them follow page-oriented, not slide-oriented design.

Do you use Wikipedia? Do you find it off-putting when the page re-loads - does it break your learning spell? Would it be more powerful if it forced you to read the whole page in order, before moving on to the next page of its, not your, choosing? Those seem to be the priorities of the e-Learning industry, in contravention of everything we know about the web.

As to PowerPoint, I simply can't fathom why the industry considers it a great pedagogical model. Death by PowerPoint isn't just a saying - it was a key contributor to the Columbia shuttle disaster, killing seven astronauts on re-entry.

Flash is great, except when it sucks

Flash is great at two things: games and video.

There are JavaScript and HTML5 games out there, but there's no doubt that Flash games dominate the online arena (with apologies for time lost wasted enjoyed from those links). Flash provides a really powerful toolkit where graphic design, interactivity, music and speed can come together to create woefully addictive games.

And Flash is still the only mainstream way to deliver video online. YouTube has an HTML5 trial, but due to a format war between the major browsers, Flash is still more compatible all-round.

Flash sucks when it's used for navigation and for presenting content. I can be quite specific about this...

Flash sucks for site navigation

Custom navigation tools: Your internet browser comes with a variety of built-in tools for navigation. These have been developed over 20 years (wow!), with various browsers vying to invent new tools and keep one step ahead of each other. The best of these have stuck, and you use them daily without thinking about it.

Flash breaks all of these. Instead, e-learning vendors have to create their own ‘players’ with their proprietary navigation: play buttons, forwards, backwards, menus etc. None of them are quite alike, so it’s an extra layer that sits between the learner and the course content.

Two broken tools are particularly egregious: the URL and the back button.

The URL: By encapsulating the entire 'experience', Flash stops me from bookmarking a page, or copying a link and sending it to a friend. To find a page that I’ve visited before, I can generally just start typing something like the title in my browser’s address bar - the browser remembers which pages match and help me find them again. The Flash course stops me from doing this.

If I want to get to a specific piece of information in the course, I have to wade through from the start. If I’m very lucky, the courseware might provide some kind of table of contents...hidden away somewhere in the custom player. Using HTML, it would be an intuitive design pattern.

The back button: Study after study has found that the browser’s back button is a core tool for web users. If I click it in a Flash course, I'm taken out of the course altogether. Clicking the player’s own back button is a mug’s gamble. How far back it will take me - the previous slide or a whole chapter?

Flash sucks for web content

Accessibility: Assistive technology tools have been built around HTML websites. This provides for a wide range of assistive needs, from browser text zooming to screen-readers and more. Flash can be made to work with some of these, but more often isn't.

Copying: I can easily copy-and-paste from a page of HTML, eg to take notes or to drop a quick quote into an email. Flash breaks this.

I hope you understand that these are profound weaknesses, even if some of the detail might be unclear. You might consider these to be benefits in e-Learning. You consider it vital to control the user journey, rather than letting the user skip through. And since the course is your intellectual property, you'd rather the user didn't copy it.

This isn't how I learn best. I don't believe it's how anyone does. If Wikipedia imposed these restrictions, would you ever go back again? Unless you’re the one with the e-Learning secret sauce, it’s not how your colleagues learn best either.

...and Flash is dead - so it kinda sucks for the future

Over the last year, Adobe has started retreating from Flash on Android (November 2011, June 2012, August 2012). Having been kept off the iPhone and iPad, this signals their demise in the mobile market.

That’s why the authoring tools are jumping through hoops to play through proprietary apps on the iPad or output HTML5. If they used HTML5 to create true page-oriented content, it would be an incredible revolution. Unfortunately it looks like they're simply using to reproduce the slide-oriented experience without Flash.

Empower the user

No software or website can compete in a free market on this basis. Users hate it and will go somewhere else, or nowhere at all. e-Learning only gets away with this kind of quality because it’s built for a captive corporate audience. But poor-quality content is still poor-quality content.

Good quality e-Learning will be e-Learning that users would choose to use, of their own volition. The experience of the internet shows that this means relinquishing control and putting it in our users’ hands - treating them as adults.

1. Ditch the sausage-machine courses that force users to sit through every page, every video, every narration. It’s useless at ensuring the users take in all the material - our user research found that they simply turn off the volume and get on with their email. And it alienates casual users from trying the course at all.
2. Need to ensure your users know the content? Test them at the end instead, with a challenging pass-mark. It doesn’t matter if they can pass the test without reading the course material - the point is to ensure they understand the content, not force them to sit through a lesson they already know.
3. Drop Flash, and embrace the full vocabulary of the internet.
4. And remember that Content is King. If you provide great learning resources, and pull down the barriers to accessing it, you users will come.

One intriguing alternative, and Google

There’s a glimmer of something new. eXe is an authoring tool that produces SCORM-compliant content in pure HTML and JavaScript. It’s an open-source product, so you can pick it up and try it for free. It installs pretty easily too.

eXe comes from New Zealand academia. Combined with its open-source heritage, that means it doesn’t have the slick marketing budget of all the commercial players. Its website speaks to internet technologists rather than eLearning specialists or corporate procurement departments. I think that’s a real shame, because if packaged and marketed well I think eXe has the potential bring the real change that e-Learning needs.

Of course the other potential disruptive player is Google Learn. Learn is if anything rougher round the edges than eXe. I’m formerly a software engineer, and I couldn’t install it easily. So unfortunately I can’t give any feedback about its features or its quality. But of course being Google, watch this space...

What’s the bottom line?

To recap:

1. Flash e-Learning derived from PowerPoint alienates users…
2. ...but it’s pretty much all the market provides

So what’s a corporate learning coordinator to do?

What’s your budget? Whatever you’re spending on the big authoring tools, it’s not worth it. Why not spend it instead on developing fantastic content in eXe? Maybe it needs a bit of CSS work, or a new interaction. That’s a great place to put your budget, instead of into online PowerPoint! At least give eXe a shot - it’s free so you have absolutely nothing to lose.

Create a couple of courses that allow your users to jump in and navigate around however they please. Throw in a pass/fail test at the end if you like. Then do some user testing - did they get more or less out of it than an expensive Flash job? Would more courses like this encourage them to come back of their own accord?

I truly hope we can shake up this industry, and if enough people learn that e-Learning is just one form of web content maybe we can. Of course if you’re an e-Learning vendor I’m offering you the chance to steal a march on your competitors. If anyone built an enterprise tool that did this, my corporation would procure it in a shot. Build it and we will come!

As for me, I think I’m about to have the opportunity to build my own authoring and publishing tool, and do it right...

…just one more thing

If you really are that e-Learning author whose non-mandatory modules are as popular as your mandatory ones, please do get in touch!

Guy

Pair-PM part 2

It's almost a month since blogged about Pair-PM, and promised to report back on how it went. So...


Our PM community was really enthused by the idea, and about a dozen signed up to the session. Then one by one they cancelled (mostly for annual appraisals) until there were 4 of us left.  Well that’s enough for 2 pairs!


I had a great chat with A - we worked through some difficulties on both of our projects. I had worries that I simply hadn’t vocalised before, and just talking about them made the answers pretty obvious. A had some concerns about collaboration with a colleague, and we discussed ways to work through those. It was great just to have a chat with another practitioner - I'm in a tech-light corner of the organisation and from that one conversation I felt more plugged-in to a community of practice than I’ve felt in a while. For me, the session was everything I’d hoped, and I think the others all found it equally positive.


Everyone remains really enthusiastic about the idea, and I've booked another session in a couple of weeks - just before the Olympics. Well some folks might drop out. No matter - I'm making it a regular opportunity to connect with my colleagues and become better at what I do. ANyone who wants to take part is welcome!


Guy

Courage and integrity - a heartfelt thankyou

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.

Guy

Pair-PM

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.

I'll post again to tell you how it went.

Guy

User Testing - Awesome Lessons

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.

Guy