Agile 2009: Many paths to the top of the (mobile) mountain

August 29, 2009 | Comments

Messy desks :)Joh and I ran our workshop, "Many paths to the top of the (mobile) mountain", yesterday.

After our dry run at the Skiff, we had plenty of changes to make to the format - mainly tweaks, and many focused around preparation. This time we went in not only with a brace of wooden mobiles, but with laminated copies of device specifications, the personas, card cut to the right size for mobile screens, and handouts.

The workshop gathered 20 participants in total (a little over double what we had at the Skiff). We had quite a few turn up over the first 15-20 minutes of the 90 minutes we had allocated, and we'd planned to divide people into teams early on. The end result of this is that we had 2 teams each containing 8 people, and one further team of the final 4 to arrive late.

We divided mobile and UX expertise between the teams - mobile was fairly well represented, UX was *very* well represented with the likes of Johanna Kollmann and Helen Sharp in the room.

I gave a short presentation on the difficulties of dealing with mobile: fragmentation, diversity of usage contexts, limitations of battery life and low processing power, all the usual stuff. We then introduced a persona, Jeremy, and the exercise: Jeremy is a keen walker and wants a product to help him enjoy the great outdoors and share the experience with his friends and family.

User testingWith that, we kicked off a 15-minute design iteration, which had both teams being a bit more conceptual than in our dry run - perhaps a function of the teams being larger and more conversation being necessary to make decisions about what to do. Nevertheless both managed to get together a product for user testing - with each producing a broadly similar product concerned with tracking walks done and local attractions of interest. A couple of latecomers to the workshop were brought into the teams as fresh meat^H^H^H^Husers and run through the product so far, then gave their feedback. Both teams then presented their work so far, and learnings from the user testing, to the whole room.

We then brought in some change: the first team, who'd been working on an iPhone-like device, were told that Apple had gone bust and Nokia reclaimed their former glory, forcing 128x128 screened clamshells onto the world. The second team had been working with a stylus-driven device and were now given a large-screen mobile with a full QWERTY keyboard. Both returned to the drawing board, to take into account feedback from the user testing and redesign their product for the new device - in 15 minutes, of course.

Round 2, debating designMeanwhile, we gave a new team composed of latecomers to the workshop a classic "candybar" format phone and asked them to design a product for this. They wouldn't get a second iteration, but they'd be able to participate, and had seen what both the previous teams demonstrated.

15 minutes later, we called both teams to a full stop. In our fictional situation time had run short pre-launch and so testing had been cut from the project. So we asked them to demo their products, and having done this, asked them all to consider a few questions:

  1. What have you learned?
  2. How did changes affect your design?
  3. What were the difficulties?
  4. What surprised you?

10 minutes later (and in a slightly rushed fashion, as the workshop neared an end - we'd been overgenerous in allocating extra time here and there throughout, which started to put on pressure) we invited the teams to present back what they'd learned.

The themes which emerged were:

  • Completely forgetting the user: despite being in a UX session and having strong design expertise in each group, the teams had a tendency to be seduced by technical capabilities. They recognised this mid-session and corrected, but there was a sense of surprise at how easily they'd drifted off-course;
  • Linked to this, the groups felt they should have done more user testing, perhaps in a guerrilla fashion even before going to "formal" user testing or to market;
  • Perhaps as a result of the technology focus of the first iteration, the change of device completely changed the product for one team. The other felt that by focusing on a core idea, they'd avoided this trap;
  • Time was short! Perhaps 15 minute iterations are a little cruel... ;)

Of these, the issue of time and the difficulty of moving between devices were echoes of feedback we had from the dry run. One of the groups this time around also starting thinking along lines similar to a previous group - considering how a user with predominately gloved hands might interact with a mobile app.

Other comments which came out from the anonymous post-session feedback:

  • One said they were "impressed how much we were able to accomplish and learn in such a short time"
  • A few attendees commented that they had a lot of fun - the buzz of conversation and the fact that, even assisted by a PA, I had to nearly shout to get groups to stop at the end of iterations had alerted us to this possibility :)

Team 3 get sketchingSo, next time around what will we change?

  • With more time, we might plug some more design activities in - perhaps in the form of a third iteration or some pre-design concept work. A few folks at UXCampLondon felt this might be a good direction to go in, though we'd need to ensure each team has some facilitative UX expertise I think;
  • We'll split into groups as late as possible, to allow stragglers to join, and to keep groups smaller. This time around we kept adding individuals to one of the existing groups when they arrived, bloating the size of them a little - each of the first two teams ended up with 8 people. I think smaller groups of 3-4 might get more done in an exercise like this, and more groups should mean more diversity in the apps produced;
  • We'll title the session better! From feedback, we scored lowest on the session meeting expectations and on the topic matching content. Next time around I'd ensure the title was much more indicative of what the session contained; I found myself picking and choosing sessions from the programme on title alone throughout the conference, and a better title would help here;

We've a tentative invitation to run the session again for one of the attendees, and we'll be at OverTheAir in late September to use it (as a couple of dry run attendees suggested) to kick off the Hack Day.

Thanks to everyone who came along and participated, to Joh as ever for kicking it into a workable shape during planning and facilitation throughout, to my dad for making the lovely wooden devices themselves, and to the organisers of the UX stage, Angela Martin and Lane Halley, for giving us a chance to run it :)

Update: I've finally gotten around to putting my slides online here.

Agile 2009: Looking back

August 29, 2009 | Comments

So, having written up the 18 or so sessions I've attended over the last 4 days, it's worth looking back at Agile 2009.

I should say first of all, it's been absolutely fantastic. There's been so much great content here - I remarked on this to Karl who commented that last year attendees referred to it as "drinking from a firehose". I'd +1 to that, the problem is not finding interesting work but making difficult decisions on which sessions to miss... and there were plenty of great talks and workshops which I couldn't get to.

There's a sense (which Mike Sutton made explicit in his session) of looking beyond software development to other disciplines. Mary Poppendieck crystallised this for me in her Deliberate Practice session, a Gladwellesque talk relating what we do to other crafts in a very general sense. In particular I've seen a surprising number of crossovers with Aikido, both in terms of people here who practice (or have practiced) both, and in analogy. Perhaps that's just because software development and Aikido are the two things I've been practicing longest in my life, perhaps it's a Californian connection, I'm not sure.

On that note, the atmosphere here has been really friendly and open; and in many ways the social structures remind me of Aikido summer schools (in a good way): you have old hands and new hands looking at the same set of problems in very different ways, sharing insights and stealing tips and ideas to the best of their abilities (again, I must emphasise that this is a positive thing!).

There's a bias towards truth-telling (lots of tales of failures as well as successes), and I've been encouraged to hear that many of the problems we experience at FP are shared by others here. I was also particularly pleased to see the amount of attention being paid to UX by people here - it had its own stage and schedule, but was also represented elsewhere, notably in the "Live Aid" project to build an iPhone app, and in the entertaining closing keynote from Jared Spool. Not having been here before I can't be sure, but I get the sense that it's been taken more seriously this year than in previous - which can only be a good thing.

Agile 2009 seems to fit into what's now a triumvirate of conferences abroad which I feel I can't miss; the other two being Mobile 2.0 Europe, and the mighty LIFT. I'm already looking forward to the next one, and I've yet to leave Chicago...

Agile 2009: Agile UX Design Emergent Practices

August 29, 2009 | Comments

Jeff PattonTo my regret, I only got to see a single session from Jeff Patton - Agile UX Design Emergent Practices, a documentation of patterns he's observed multiple design teams end up using to fit into an agile environment.

I hope Jeff gets slides online soon - it was a fantastic presentation but I was in a post-workshop slump and my notes are less than complete or useful:

  • UX practitioners find it hard to adapt to an agile environment. They typically go through the five stages of grief as they adjust;
  • Jeff was one of the first people he could find to go through this, "the tallest of the pygmies" as he modestly puts it - until he found Craig Villamor of Salesforce;
  • Why is it so hard? Jeff theorises it's about homonyms - words which designers and developers use, with each applying different meanings;
  • For instance, to a developer, design is "how"; to a designer, it's "what"; for a developer an iteration is a timebox, to a designer it's a representation of the product; and so forth;
  • Patterns have emerged! For instance...
  • Design work getting chunked effectively: good designers working in agile teams learn to do this well;
  • UX as part of the Product Owner or customer team;
  • Product Owner as a team blending many skills, not an individual;
  • Internal product releases to break up the sometimes long periods between public releases;
  • Learning how to do "just enough" work up front, in a "sprint zero" which can take place "whilst the developers are getting CruiseControl working" - much knowing laughter from the room at that one;
  • UX owning, or co-owning, the product backlog;
  • Use of story maps;
  • Owning a time machine, in order to travel forwards and backwards during the project; in each sprint evaluating work from the previous sprint, supporting the developers on the current one, and doing research for the next;
  • Cultivating a pool of users who can be available for user testing at short notice, and using these users to do post-testing of existing software and pre-testing of prototypes;
  • RITE testing (James Box wrote a nice intro to this a while back);
  • Letting a prototype and conversation be the specification, instead of relying on documentation;
  • Having "designer/developers" who get their hands dirty with code;

Jeff ended with a lovely assertion: that whilst adapting to agile was difficult, he thinks that using agile leads to better-designed products than traditional methodologies. /me claps until my hands fall off.

Agile 2009: Agile by the numbers - what people are doing

August 29, 2009 | Comments

"Agile by the numbers - what people are doing" was a talk by the enjoyable spikey Scott Ambler. Scott had been running some surveys to try and get to the bottom of what agile teams were actually doing - as opposed to what they claimed to be doing. Scott hypothesised that there's a bit of a macho developer culture which perhaps inhibits the ready dissemination of truth :)

His findings:

  • 76% of organisations "do agile" - it's not a marginal practice any more;
  • Within these organisations, only 44% of the teams are "doing agile" (he doesn't try and define what this actually means, this is according to the teams definition of agile);
  • Teams of up to 10 developers tend to succeed more: agile seems to be easier with smaller teams. But that said, there are lots of people succeeding with larger teams;
  • Most agile processes *are* empirical;
  • 3/4 of teams using agile are doing legacy projects - i.e. it's not only used for greenfield development;
  • Only 42% of agile teams are colocated - another 42% are driving distance or further apart;
  • 56% of agile teams produce documentation in the form of a "vision document";
  • The average agile project takes 3.9 weeks to warm up, before code starts being written - developers aren't typically diving into building stuff immediately;
  • According to a fairly exhaustive DDJ survey, agile works better than other methods;
  • 70% of projects are accurate to within 30% of their best estimate. The other 30% of projects are less accurate. But most businesses require projects to be accurate to within 9% of the original estimate;

Agile 2009: The Agile CTO, Diana Larsen and James Shore

August 28, 2009 | Comments

Diana Larsen and James Shore presented "The Agile CTO", a session for executives (oooh get me) which had the aim of bringing out and discussing a few consistent concerns that they have about their position.

  • Their research was based on interviews with 8 CTOs from a variety of companies - sized from 8 up to thousands;
  • Many felt the shift in priority as they moved from manager to CTO, quite keenly;
  • Priorities changed from "how this project is going" to "how the share price is doing";
  • They had a need to retain credibility by meeting commitments, and by not being surprised by bad news (there was a sense that it's the surprise that causes problems);
  • They spoke of trying to create an environment where mistakes are not punished, but are accepted and analysed;
  • Another consistent theme was time spent dealing with emotional baggage of team members;
  • They were also a consistent love of seeing people excel, or watching their teams come up with amazing stuff that completely surprised them;

We then broke into groups to discuss other consistent themes from our experiences. Our table came out with:

  • The need to keep abreast of industry trends and have a position on them, and how they affect our business;
  • Balancing new product development and "lights on" maintenance activities;
  • Representing business issues to the technology side of the business, and technology issues to the rest of the business - effectively being a conduit for information both ways;

... and some others, which I never wrote down, so they'll be lost to civilisation forever.