agile ux · conferences · UCD process

dConstruct – Questions on Agile UCD


I had the opportunity to present a talk on the power of iterative methodologies over waterfall at dConstruct last week (a.k.a Waterfall Bad, Washing Machine Good). This is an extended re-mix of a talk that I gave very briefly at the IA Summit earlier this year (I also presented a similar talk at UX Week recently).

I will put my slides up as soon as I can get the file size low enough to get them loaded on SlideShare – will need to get in and optimise those post-it note photos I’m afraid! In the meanwhile, here’s the slide that most people have expressed interest in!

Not to make any excuses, but this is a really tricky talk to give. To get to the meaty bit – the bit where the UCD and the Agile come together, requires a base understanding that Waterfall methodologies (or sequential methodologies) suck, and that iterative and incremental and collaborative/cross-disciplinary methodologies are the way forward. It also requires that you have a working knowledge of Agile.

Lots of people assume that everyone has both of these things, but I can assure you they don’t. If everyone *knew* this, then there’d *be* no waterfall shops out there, right?!

Nonetheless, the most interesting part of this talk is getting down to tin tacks on HOW we can give Agile more UCD flavour – to actually integrated UX activities into a sustainable agile pattern. And this can be pretty tough.

I have to say that while I’m 100% committed to the overall idea of Agile UCD being the methodology of choice, I’m more or less committed to some of the assertions I made in my talk… (is this naughty? I just wanted to take a position for the sake of conversation, and I had plenty of those post-talk!)

For example – one of the things I said was that I think that Agile cycles (or sprints or whatever you call them where you are) need to be longer than 2 weeks. That it takes that much time to fit UX activities into a cycle. I *think* I believe that this is true, if you’re going to do solid UX work in an Agile environment as well as be there in a ‘paired’ environment getting the functionality built. More than one person suggested to me later that perhaps the same end could be achieved by just doing less in a two week sprint. Perhaps.

I don’t think there are any clear rules on this yet… at the end of the day, what I *do* want from this discussion is for UX practitioners to feel comfortable engaging in the discussion about how long a cycle should be with the rest of the Agile team and to not back away from the discussion when rebuffed with a simple ‘well, that’s the rules’, or ‘that’s just the way Agile works’ argument. Again – if your team doesn’t do this then consider yourself fortunate. There are lots of designers out there trying to eek their way into an established Agile environment who come up against this kind of resistance all the time.

There was another series of questions that I got from LOTS of people – and a very valid and important questions they are too…. I’m not sure I have the best responses so I’d love to get feedback from you on what you’d do and say.

The questions are around how do we sell Agile UCD to our organisation and to our clients? How do we manage the fact that this agile approach takes away the security blanket of knowing what you’ll get and when you’ll get it that Waterfall apparently provides.

When I was talking with people about this at dConstruct, I found myself saying these two things repeatedly, and it seemed to elicit nods and smiles and general agreement/enthusiasm.

The first is that whilst in waterfall you might know what you’re getting at the beginning – you have no reason for confidence that you are getting the *right* thing at the end of the process. And, in Waterfall, there’s no real mechanism for changing your mind or learning from the project itself as you go. You can very easily end up with the wrong thing, and then spend a whole bunch of time and money changing everything around so that it’s right – and you’re changing things at the most difficult (read: most expensive) time to be changing things!

So, what this means is that the ‘security’ that Waterfall appears to offer is really, in many cases, false. And although the budget for the project may be fixed at ‘x’ – no one knows what work will be required once the project is completed to get it into it’s correct state. Or the cost to the business of not having got the project as good as it could have been.

Make sense?

The second point is that we can ‘charge out’ Agile in a very different way to Waterfall. Although it would be nice, your client doesn’t *need* to commit to months and months of development work in an Agile environment. They don’t need to commit to the full budget. In fact, they *could* potentially just commit from cycle to cycle. Your company/department can calculate the cost of a cycle, then with the client, negotiate what work will be undertaken in that cycle… rinse, repeat etc.

Of course, this is not really the ideal way to be running a business and you’d hope that, over time, as your clients got more and more clued to the benefits of working Agile rather than Waterfall, they’d be more willing to make longer commitments to the project, making your cash flow a little less precarious!

Fact is though, you do need clients who are clued into the benefits of Agile and Agile UCD for their projects. If they don’t get what’s in it for them (and there is plenty!) then there’s no way you’ll sell them on it. So, knowing those reasons yourself and then educating your clients is a big part of the process.

It’s not easy though, and we’re not going to be in a state where we can be all happily Agile UCDing tomorrow, next week or even next month.

It is, however, without a doubt the ideal way to run your projects. It’s going to require a lot of thought, a lot of work, a lot of trying things out, and a lot of educating our clients and other people in our organisations.

I think it’s going to be worth the effort!

In the meanwhile, lets start sharing ideas and experiences.

How would *you* answer these questions? What questions do you have? What’s been your experience with Agile and Agile UCD?

14 thoughts on “dConstruct – Questions on Agile UCD

  1. I think you’re right about longer than two weeks. You need time to think about the problem and solutions and poke at some stuff in your heads *before* you poke at real iterations, no matter how agile and rapid they may be.

    But the two weeks doesn’t have to be this scary time where developers are twiddling their twitters. Once it looks like the developers are on their way with something, we start thinking and poking about the next bit.

    And a couple of times, with more strategic, architectural bits of the experience, the work we get done in that two week period has implications to fill a dozen developer sprints. Again, it gives us time to think about other things.

    One thing I like about your diagram is that the product/biz people are not included. Here, they’re heavily involved, and iteration becomes endless change requests. Boo!

    I think the neat part about agile is that it closes communication loops more efficiently than *traditional* waterfall processes. (I also think it’s still basically a waterfall process, but unless you can make like my laptop and step outside the bounds of time, then you’re stuck. Dr. who?)


  2. I really like your first point about the security of what you get and when you get it – I’ve not heard it expressed that way before, but I’m definitely going to borrow it if I may.

    Regarding the two week issue – I think it’s really useful to get that kind of guidance for people who are just getting into agile dev. Coming from a UCD background into agile I think it was always one of the concerns I’d had about how to introduce agile.

    However another aspect that I’d be interested on hearing your thoughts on is how to run different development tracks for a website using agile. Most of the case studies I’ve read about talk about software development where your building up to one major release, where as often with web stuff you’ll have a major dev path, a minor dev path and then a day to day maintenance path and so far I haven’t quite go t my head around the interplay between these and agile UCD.

  3. Hi Leisa. Thanks for the talk at Brighton, a high point of the day for me.

    I did initially want to hit a fast-forward button but you got to the UCD / agile combo stuff soon enough. Nicely relevant for my team because we’ve just finished our first sprint using Scrum on product development for a community-focused CMS. We used a 4-week sprint and we did rather lose track of UCD/UX focus, e.g. personas did not play much of a part in the discussions. I’m quite certain we’ll be looking at introducing some of your ideas soon.

    My experience of beginning an agile adoption is that development gets all the attention, there’s very little background info for QA, outward facing project management and particularly for client engagement and sales folks. I’m truly fortunate working for a CEO who buys into agile, that does help a lot. UX is another area that’s lacking in guidance – we know we want to do it but didn’t have much idea of how to fit it into the pattern previously.

    Regarding your diagram (thanks for posting, I was trying to frantically scribble it down at the conf) – makes a lot of sense but I have questions!

    * You don’t always know in iteration n which stories are planned for iteration n+1, are you suggesting this is fixed a whole iteration in advance?

    * How far would you push the multi-disciplinary thing? I have one UI specialist and five backend java developers, should I encourage everyone to do UI and even UX or have specialists for that?

    Many thanks
    Alex Francis

  4. For sure, your talk was one of the most debate-worthy of all the sessions at dConstruct.

    Apologies for the lengthy comment…

    I have spent the last year looking after a bunch of User Experience people doing a mixture of UCD with the SCRUM/XP-based agile methodology (named Factory), and a blend of our own Rapid Innovation Prototype Lab (RIPL) type projects. RIPL often, but not always, acts as a more exploratory UCD pre-cursor to some of the Factory stories and so I would disagree with one of your slides which illustrated upfront UCD not working as well – I believe it is often essential, but in conjunction with some more closely entwined agile/UCD through the core dev iterations.

    As for extending the iterations/sprints, I quite liked the 2 week turnaround but its really difficult for developers and UCD people, partly because of the habits you need to form and the amount of administration that you cover in an Agile process. I don’t agree with 4 week iterations because that seems too long and you lose the energy. The way I would suggest you deal with the difficulty of testing when using such short iterations is just wait for several iterations to pass and then test a number of things at once. I say this because you often don’t have much to test after each iteration – not enough to warrant the hassle of recruiting, analysing, reporting etc. With several iterations of code/site/application to test, you can do an 1hr or maybe 45min sessions with users, recruit in advance (eg, every 2 months), and have time to report on the learnings and write appropriate stories for some upcoming iterations. That’s the way I see it anyhow.

    With respect to selling Agile, I think that is one of the biggest problems we face. In my company, several sales people have gone out preaching Agile but have not really explained waht the level of commitment needs to be form client etc. Clients can’t get to grips with not knowing what they are getting, that’s why they needed to be taken on a journey. We were lucky in that we had a painful Waterfall project previously with our client and so it was easier to get them bought in. They were happy to invest some time from their side and invest in us setting up our way of working. We also had an Agile coach, which I think is absolutely essential if you haven’t done effective Agile before.

    The way I would sell it now is to explain the pitfalls of a traditional approach like you mention and be sure to sell some upfront work to really clarify the potential directions they may want to go in, and then go through in detail how they will ultimately take part, with the team, in controlling the priorities weekly, so that they can choose to improve a feature based on user feedback or tackle another feature. They absolutely need to know that they will be largely responsible for making these trade-offs and that the team will be as transparent as possible. The huge carrot for them, and when they really start getting engaged is when they see progress after 1-2 months rather than a year.

    Anyway, i’ll leave it there, otherwise your posting will become unreadable, but i sure have lots to say on the matter – talking from some real full-on experience of the last 15 months.

  5. Great post Leisa. You really nailed it on the “selling it to the client” front. I completely agree with Alex’s comment: “My experience of beginning an agile adoption is that development gets all the attention, there’s very little background info for QA, outward facing project management and particularly for client engagement and sales folks.”

    My experience to date has been primarily in software development companies where we were the client, so much easier to sell ;) And my experience has mostly been on the development side.

    We are just doing our first project using agile methodology for an “external” client. We had a number of internal debates about how we’d be best presenting the concept, but I explained it to the client much the same way you did.

    In this case it worked, but there was timeframe pressure – they wanted to know when they could launch so they could ramp up their marketing efforts. So there was still a sense of “what do we get and when will we get it” – which was hard to deal with. (In the end the launch date has been pushed back for other reasons, so this is less a concern now).

    We are running 4 week cycles – we can hardly call them sprints ;) – and we outline the key deliverables to the client at the beginning of each iteration, and provide a budget. We still have an “estimated” launch delivery in about 3 cycles, so they have a picture, based on iteration cost, on the overall budget.

    (Mind you, this is on the basis of the job kicking off with a full estimate put forward before starting the job, so we are also mindful of keeping within range of that.)

    I also agree with Jason’s comments about testing. We aren’t testing until at least the second iteration (other than bare-bones – “can we demo this to the client” testing).

    In my previous role we were developing a software product and even though we had over 1,000 unit tests the testing became the biggest issue. It is especially problematic with large projects as they grow – you can’t unit test everything (much as I’d like to!)… So doing internal sprints, then, say, a release after 2 or 3 iterations would probably make a lot of sense…

  6. I’d be very hesitant about making iterations longer than two weeks. They’re as short as they are for a reason – folk need the tight feedback loops for the other practices to work to their full effect. I’ve found that iterations much longer than a couple of weeks means the other practices start to become considerably less effective.

    I think the folk who talked about “just doing less in a two week sprint” are on to something. That’s certainly been what I’ve been doing. I produce less in the way of artefacts and spend more time doing lo-fi work and talking to / teaching folk when working on agile teams. It really is surprising how quickly you can move once you remove a bunch of sign-off/handover tasks.

    That said – some things do take longer than a couple of weeks (although not anywhere near as many as some folk think once you’re embedded in a team). Often the things that sit more on the Customer side of things. The thing is – the iteration length isn’t the only feedback cycle you have to play with.

    For example, if we look at XP we have feedback loops on many scales.

    * minutes/hours (e.g. test-driven design)
    * days (e.g. daily stand up meetings)
    * weeks (e.g. iterations)
    * months (e.g. release plans)
    * quarters (quarterly cycle)

    Much work can be pushed down into the tight-cycles, but some of the more strategic stuff naturally sits at the level of release plans, quarterly cycles, etc.

    I think it’s worth the effort too :-)

  7. Just reading Adrian’s comments – it’s actually interesting – we’ve kinda fallen into a 2 week cycle even within the 4 week iteration. There were things going along for the full four weeks (documentation etc.) but most of the tasks were really able to be broken down.

    The nice thing about the 1 month cycle is:
    * better cashflow
    * easier for the client to grok
    * we get a good body of actual outcomes (deliverables) so the client feels they’re getting value for $$ – at 2 weeks we had very little to show for the work.

    I also have to say we’re not doing true XP style agile development – we’re kinda trying a hybrid approach of our traditional model (which still isn’t waterfall, but certainly not as agile as this project).

  8. Wow, great discussion starter, and a nice addition to your talk at UX Week (which was great, by the way).

    We’ve settled on a 4-week iteration/sprint/cycle that seems to work well, though we’re still working out the kinks. We also do an “Iteration Zero” that provides the whole team a chance to walk through all of the concepts, ideas, information and tech that could possibly come into play as part of the development project. It’s a chance to prototype, play with new technologies/tools, brainstorm and bend the rules a bit. At the end of it, we have a well-developed sense of where we want to go and how we (might) get there.

    We also blend iterations … the last week of one iteration is the wind down of development for one part of the project and the time for ramping up for the next part. We review, adjust, tweak and prep for the next piece of the puzzle.

    From our past experience, anything less than 3 weeks is too little, anything more than 5 is too much. Frustration and apathy/boredom result, respectively.

    Thanks for starting this conversation and keeping it going … always something more to learn!

Comments are closed.