Sunday, 13 March 2011

Agile is broken

I've been managing web development teams for 15 years, and it's always interesting to learn how other teams deal with the same challenges we face.

Strong opinions abound as to the extent to which agile should be implemented in a team which builds websites. I used to work at BT where agile development practices were so deeply ingrained that anyone not fully agile was viewed with derision - no doubt arising from bad experiences (Update 19/3: there's plenty of non-agile behaviour in BT, and the previous link was aimed at them. See Kerry's response below). But, coming as I do from a design-led background, this never sat entirely comfortably with me. In my experience, websites (and other products) not considering design from the outset are pretty awful to use. There are of course exceptions, but I haven't worked on them, and I think they're pretty rare. Maybe the project team had a developer with strong design sensitivities? A rare beast indeed.

The shortcomings of a waterfall approach are well documented - and learned first hand I should add. By doing all the graphical design (and too much documentation) up front, it restricts the chance to iterate during build and learn from testing. The process takes much, much longer and you end up with a poorer product which is difficult to fix. Unhappy customers claim this isn't what they asked for. All this is well known.

But the shortcomings of agile aren't often aired in public. When you implement one feature at a time, and build out from there, strategic vision often gets overlooked, as does design integrity. User experience and overall aesthetic tends to take a back seat. There's little consensus up front on the final solution, which means there's a level of uncertainty about how current work will fit into the solution down the road. The larger the team, the more these effects are amplified. And from an agency perspective, clients usually tender out work based on functionality agreed up front - if you're unwilling to commit to this, they'll go elsewhere.

There are several options that try to blend the best of both worlds, outlined in a session here at SXSW by Karl Nieberding (eBay) and Kris Corzine (Wells Fargo). These include "Mini-waterfall", where you put developers and designers in every sprint. The problem is that you get the same problems as full on waterfall (though less pronounced). There's also "Just in time", where designers work two sprints ahead of development, making sure design work is available when developers need it - and there's a sort of interim design vision to work towards. But then you lose agility and flexibility. You can find yourself working on three sprints at once - next, current and last (for testing). There would be too many complex interactions and versions to track - a huge loss of focus.

The system that works well for us at The Team, endorsed by the speakers here, is a system of partnership between designers and developers throughout the life of the project. There are steps you can take to reduce the waterfall risks, getting developers involved in the design process. We test (at best) or peer review (at worst) throughout the project based on whatever assets are available (sketches, wireframes, early designs, prototypes). Most of our projects are fairly short anyway (1-3 months), reducing the risk / impact of upfront design. And when it comes to build, we adopt standard agile development techniques, using e.g. kanban charts, scrum meetings, and other agile practices.

We've found this works best when we put a lot of emphasis on effective kick off meetings. This is the chance for everyone to contribute towards the vision of the project, and for all to understand what it is that's motivating the customer. A good kick off meeting is critical.

It also places a lot of emphasis on the sketching phase of the project. By kicking around the various approaches in sketch form together, designers and developers can explore the best way to solve problems. Then during design the developer can be thinking (possibly subconsciously) about how the solution might be built.

The proof of the pudding, of course, is in results. As well as defining KPIs at the start, we get a sense of success from whether our customer is happy and if users are satisfied. I'm pleased to say that we've had a lot of success implementing this approach, although the fact we improve with every project shows that we have a lot more to learn.

I'll leave you with the 7 rules of engagement as provided by the above-mentioned SXSW presenters:

1. Shared vision - defined clearly at the outset

2. Engage team - ask for input from everyone, but make it clear it isn't necessarily a democracy

3. Stakeholder buy-in - risk involved, but also reward

4. Excite with prototypes

5. Sit together

6. Communicate - build empathy

7. Get out of the way - once you've established working patterns, support rather than dictate

I can't emphasise No.5 enough - in my experience, all of this falls apart if you're not in constant communication. I don't just mean meetings (which we try and limit), I mean the awareness of activity across the team and involvement of people at a time convenient to the project.

And there's one more thing missing from this - I think the team can form around clearly articulated and prioritised software requirements. This helps drive assumptions out of the system, bringing crucial alignment to the thinking going on in the group.

A game which is broken

Seth Priebatsch (of TED talk fame) gave a keynote here at SXSW which focused on game mechanics, touching on the areas where he feels there is huge potential for application. These include loyalty, customer acquisition and global warming - but his most useful comments (I thought) were about education.

He sees school as "a game which is broken". Schools are near perfect game ecosystems, containing motivated players, challengers, awards, rules, allies, enemies, levels, appointment dynamics, incentives and disincentives and yet we've based education on the wrong rewards. We've replaced the real reward (learning) with a fake reward (test and exam results).

He unpacked the game analogy further; grades are simply levels, and based on that analogy you should never be able to level down. There's currently too large a focus on failing - it should be based on progressions instead. We should start with e.g. zero experience points, so we can then focus on the positive progression through the system.

He had some interesting views on cheating, too - the current disincentive isn't on cheating, it's on getting caught. People learn how to play the game based on how you've designed it. He was educated at Princeton, where he says cheating has been greatly reduced there (from 400 examples per year down to 2), by getting students to write the honour system themselves and sharing the burden of reporting cheating - complicity is treated as much a crime as cheating itself. So, when they take a test, there is no teacher, no admin of any kind. The mentality has changed so the "enemy" is no longer the teacher - it's the test, and you get there together.

At The Team we've got several projects on the go that focus on education, for both children and adults, at school and in the workplace, and it set me thinking about whether the mechanics in those systems can be improved. How effective would it be to influence educational systems via the IT systems which are supposed to help? What are the moral implications? Other than using the Princeton anecdote, what other information do we have to justify a modified design approach?

This also needs to be considered alongside something called the Hierarchy of Cognitive skills. It's one thing to repeat something learned by rote, but the real goal is to progress through the levels through understanding, applying, analysing, evaluating and creating. My gut feel is that the focus on the appropriate rewards would help move more students through this process.

Lots of food for thought!

Saturday, 12 March 2011

The message is the medium

I'm attending the SXSW conference in Austin, Texas, and will be posting notes from the best sessions here. All of them obviously written in a hurry, and some of which may even make sense!

First up is an excellent presentation from Josh Clark (@globalmoxie), who talked about iPad design headaches. All examples listed here are iPad apps (Update 14/03/11, his slides can be found here).


iPad users have a low resting heart rate...sitting, reclining, a device of leisure and recreation - and this should drive a lot of the design decisions.


Avoid "greedy pixel syndrome" - continue to recognize the value of white space. Don't just jam in the information. Let me ask for it when I need it. Create an environment of "ask and answer". Make each tap satisfying. Think: tap quality is more important than tap quantity.


Media hypertrophy / overkill - it's tempting to focus on first time use, but more important to consider people using them every day. Example: ABC news website has an awful globe thing showing all the videos - good for demos (perhaps), but a bad presentation of news, much of which can't be seen - and therefore poor for repeat usage.


Supress the urge to show off. Focus on the content more than the form. Example: Solar walk. Sophisticated interface, but it falls away so you can focus on the content. Example: Marvel comics, great example of how to get past the interface, get to the content. Example: New York Times - familiar isn't always bad.Example: Flipboard - comfort and familiarity. And people love it. We have centuries of know-how when it comes to presenting text - lean on it.


But don't be too tied to analogue - are page flips necessary? Feedback is good, but speed and feeling are critical. Don't distract.


Side note: iBooks enables page flips, but on iPad calendar / contacts, even though the information is shown in a book form, swipe to turn page doesn't work. Actually deletes contacts!


Ask: Is different actually better?


Avoid metaphor clutter. Choose one and make it work. If it looks like a physical object, people will try to interact with it. Example: App called "Manage" uses several real world metaphors that make you want to interact - but you can't.


Avoid popover pox. Example: Twitterific is great, but should just use popovers for quick peeks - not for extended exploration.


iPad elbow. "I hate the iPad's back button with the heat of a million suns" - too small, too high. Example: Twitter app does a great job getting rid of the back button. Think: Where do your fingers naturally come to rest?


We're so used to mouse pointers, but using fingers to touch changes things Psychologically, Ergonomically and Emotionally. "Big screens invite big gestures"


The old adage of the medium being the message is now turned on it's head. Now, "the message is the medium". "Buttons are a hack". 2 year olds have a fresh perspective on this.


Explore multitouch gestures. Example: Uzi draws you into experimentation. (From a chat I had with him afterwards: What affordances can you give to show multitouch gestures are available or enabled? For more conventional apps, you obviously need to avoid presenting multitouch options up front, as this would probably confuse the user as they're getting started. Maybe consider hiding them under 'help' settings, or showing a couple of circles flicking across the screen to hint at the functionality. Another option is waiting until say fifth time of use before being more explicit. And then perhaps repressing the hint when you'e detected that the function has actually been used - although remember that iPads, unlike iPhones, are often used by more than one person)