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!

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).

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

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…

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.