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.


Benjamin said...

I have to admit at first I thought I'd have to try to argue here in this comment but you veered off the rant mid-way. Chapaeu to you.

Obv. you've many years more experience than I but my naive view is that, perhaps some of your initial points are a little insular.

Regardless of the development process the agency and the client will have a strategy and (i trust) with Agile both sides get the opportunity to feedback based on whether the iteration fits with that strategy. Similarly design *could* work this way but, in reality design and development are deeply intwined which you justly raise as an issue.

Sounds like you have a pretty good way of working at the team though, would be great to hear some other views on this from within the team so I implore you to either link to posts or encourage some commentary here. :)

DE said...

It is true that agile tends to try to push design around the plate and not actually chew it.

The hidden process is that one person who actually has a design strategy and end goal in mind communicates this with the team WITHOUT ATTEMPTING TO OWN IT.

Without an end design, each team member will simply rebuild the last project they were on. If someone holds onto the design, it will become rigid.

In short, there has to be a design, it has to be communicated and it has to be malleable. Agile just fills in around this.

Kerry Buckley said...

I wasn't going to rise to the bait, but as you seem so keen for people to argue with you…

Firstly, your title doesn't match the meat of the post. No sane agile methodology suggests doing no analysis or design up front – the key is to just enough, and at the latest responsible moment. Websites, and especially websites that need to have a strong visual style, will no doubt need more up-front design than some other types of product. All your points about strong kick-off meetings, designers working with developers throughout the project, and everyone sitting together, are spot-on, and exactly the kind of thing that agile encourages. I only wish I'd had a designer on the team in projects I've worked on, but sadly it's usually been a case of the developers doing the best we can to cobble together something not too ugly or unusable, with no expert help.

Secondly, I think there's a lot of confusion about "agile versus design" that comes from the overloaded nature of the word "design". The up-front design that agilists tend to rail against isn't graphical or UX design: it's the kind of formalised heavyweight software design where someone writes a document and a bunch of UML diagrams describing how the code will be structured, before they (or even worse, someone else) can start doing any development.

Finally, the fact that you quoted the Half-Arsed Agile Manifesto as proof of how deeply-ingrained agile is in BT is hilarious. It wasn't aimed at people who weren't "fully agile", but at big organisations that try to adopt agile, but just pick up the buzzwords and a few peripheral processes without understanding the core principles and values. Where "teams" who've never met have hour-long "stand-up" meetings on the phone. Where people claim to iterate, but "user stories" are just renamed requirements specs which are signed off in blood before work can start, and where nothing is demonstrated to the customer for six months. Although it seems to have resonated with lots of people in the wider world, the original target was much closer to home.

Phil Whitehouse said...

Hi Kerry, thanks for your post. No trollism intended - but keen to learn from different perspectives.

In fact I think we're quite closely aligned in many of our principles, but may differ in some. For example, when we talk about 'just enough' design being performed up front, my stand is that substantial design needs to be completed up front if the finished product is going to be usable and stylish. This in turn leads to quite detailed definition, which flies in the face of agile somewhat.

But perhaps this works for us because the type of projects we run are smaller than most of those at BT, and we can mitigate the risks by involving the developer in the design process (and vice versa). It's interesting to understand how other teams handle this dilemma and I'm sure there's room for improvement. I always thought it unfortunate that talented developers at BT aren't given the chance to work closely with talented designers, especially given the business division is called 'BT Design'...

From where I was sitting (admittedly outside the BT mothership), it seemed as though everyone was an agile advocate - perhaps I was just lucky to meet the right people. I've updated the post accordingly.

We're definitely on the same page when it comes to writing detailed functional specs. We simply don't produce these at The Team, and when annotated wireframes are getting too complicated or detailed it's a sign that the project needs to be broken down into smaller phases.