I found your blog from your Twitter profile as well, and wanted to thank you for validating my experiences with the Agile Method! (I thought I was going insane all by myself.)

As a UX Designer, I wanted to give a +1 to the developer who recommended a prototype being developed alongside the product. We have had some challenges with developing usability in tandem with new features, and are currently developing a prototype that will be wired into the main product as part of the sprint.

Found your blog from your twitter profile. Wanted to say i that i also find the redesign of website/application much easier than to design from scratch and that has become my speciality these days.

Naturally 2nd and 3rd generation websites are challenging to rebrand as clients have been through their first most probable “bad experience”. They realize that they actually need to dish out some cash and get it done professionally.

We have also established an agile web development team and much like yourself are trying to get with the program! I’d have to agree with @Dave Sherohman about why Agile code is less buggy – it does make alot of sense.

Well thanks for the great reading and your insight into the universal experience! Excellent and well thought out content! Many thanks…

Ahad
http://blogspot.fluidewmedia.com

It sounds like your method of fixing the UX is to do a waterfall project. (2-6 months) It totally depends on the organization and the product, but if the product has alot of pieces you could improve the UX in smaller chunks with an agile release schedule.

I love the big bang approach myself and sometimes it’s the only way. But its not ALWAYS the only way.

“Even if it’s a major workflow overhaul which needs to be presented to the users as a single changeover, the underlying functionality can still be developed in month-sized chunks until it’s ready to support the new workflow while keeping all those changes behind the scenes (at least as far as the public UI is concerned), then, when that’s ready, 4-6 weeks to change over the interface all in one shot should be sufficient.”

Thanks for this feedback!

I have a hard time accepting your assertion that there are interface changes which a) will take over a month to implement and b) must be released atomically (i.e., “all or nothing”). Even if it’s a major workflow overhaul which needs to be presented to the users as a single changeover, the underlying functionality can still be developed in month-sized chunks until it’s ready to support the new workflow while keeping all those changes behind the scenes (at least as far as the public UI is concerned), then, when that’s ready, 4-6 weeks to change over the interface all in one shot should be sufficient.

In the ideal case, there would also be a separate project running in parallel to prototype the new UI and get user feedback, usability tests, etc. via Agile methods (as mentioned in an earlier comment) so that it’s all ready to be put into place once the back end is prepared to support the new workflow. Unfortunately, in the real world, there rarely seem to be the resources available to allow this.

On your side question of how buggy Agile code tends to be, the answer is “not very”, for two primary reasons:

1) Automated testing (and, often, test-driven design) figures prominently into Agile methodologies – it’s often considered one of their defining characteristics. A good test suite helps to find and fix bugs quickly, then ensures they don’t return.

2) Shorter release cycles mean less time (and fewer new features) for bugs to creep in on each release. They also mean that, when bugs do appear, they get fixed faster.