“We’ve found the most successful teams are those that spend as much time in each iteration measuring their designs as they do implementing it.”
Jared Spool, in an interesting article on making agile iterations… agile! I have found the situation he describes over and over again—agile teams organizing a series of sprints, but never really iterating. They are basically doing waterfall planning, just on very short timescales. This article gives direction on how to get out of that rut. And no surprise, it relies on robust design and user research processes.
posted by
ted
11 hours ago
Essential UX Layers—an interesting model from Jared Spool for tying together your vision, design principles, personas, scenarios, and user stories (or feature designs or use cases or whatever). He presents this as a way to help user experience design fit into an agile development world, but the layers would work well in traditional dev methods as well.
An important point that might be lost on some readers—many of the layers (all?) are rooted in user research; you don’t just make stuff up and expect to solve real problems for real people.
posted by
ted
on Wednesday, May 11, 2011
“When you treat estimates as promises instead of guesses, you bind your worth as a worker to it. If you do not meet your own deadline, you are a failure. And since nobody likes to be a failure, they’ll indulge in risky behavior to avoid it, like burning the midnight oil and checking in bad code with scanty or no tests.”
David Heinemeier Hansson, It’s not a promise, it’s a guess
posted by
jason
on Wednesday, Feb 03, 2010
case study
In October, I attended a session by Jeff Patton at UIE13 on doing user experience work in agile environments. I found it extremely helpful in understanding how to improve the process on my current team. I have not yet “arrived,” but the principles learned there have had an actual impact on my processes, as opposed to the “feels good but what do I do now” impression you sometimes get from conferences.
In a “re-print” from last August on UIE’s newsletter, Jeff outlines 12 principles for UX in an agile environment. Here’s a summary of the points in his article (originally broken into part 1 and part 2), with notes on how I have applied these principles to my current project:
posted by
ted
on Tuesday, Mar 03, 2009
“It takes a strong
UX practitioner to stand up to an ill-informed team who think that Agile is about
speed rather than about better project control, and who subsequently think that user
experience work is a waste of time.”
Looking forward to reading the rest of Nielsen/Norman’s Best Practices for User Experience on Agile Development Projects
posted by
ted
on Monday, Dec 01, 2008
Facinating article in Wired magazine called Halo 3: How Microsoft Labs Invented a New Science of Play. Wired takes a close look at Bungie Studios, the makers of the massively huge Halo video game series, and how the Microsoft-owned company utilizes state of the art usability labs to test their video games. It appears Bungie is following some principles of the agile software development methodology, with constant revision and tweaking in response to an extremely detailed look into how players move through the game. It’s obvious the games would be nothing if not tested this way. Pretty interesting look into how video games are designed and refined.
posted by
jason
on Saturday, Sep 01, 2007
“One of the great things about agile is that it seems to get developers “hooked” on having impact on people, as opposed to being hooked on writing “cool” and fun to write code.”
Alain Desilets, via the “Agile-Usability” group on Yahoo
posted by
ted
on Monday, Feb 19, 2007
Our development team is getting great mileage from 37Signals’ Backpack application to share to-do lists and knowledge about our project. Randy and I are currently working on an internal web application for the Physical Facilities department of the Church, an app so big that we have seven developers, four QA engineers, two DBA’s, and a few managers to keep tabs on it all (about twice the size Flickr’s team).
We use a mixture of Extreme Programming and Agile / Getting Real methodologies, with pair programming (and pair designing – more on that later) and two-week iterations. We are having a lot of success with this approach, most of which coming from prototyping and user testing the app before it hits development, and using the prototype as our spec. We have very little documentation – the prototype is it.
But recently I started using my Backpack account to manage my to-do’s (an upgrade from paper scraps). I then added a few short lists to keep focused on the major features of the next few iterations. Then it hit me – I shared the page with Randy, and we started adding things to each others’ lists, pushing things onto a “future enhancements” list if it fell below priority.
Then we shared the page with our business analyst Pablo, who signed up for an account and started keeping his own list of to-do’s, a list on which Randy and I could easily jot down business questions for Pablo to answer.
And just last week I shared the page with Lohan, our lead QA. He signed up for an account, and created his own lists of questions for Randy, Pablo and me, and we just edit the to-do’s with answers and questions of our own.
The lists are ever changing and easily added and deleted. No history is kept; none is needed. A list usually lasts about one iteration, and after those two weeks I wipe it and start fresh.
The best part is the app has little barrier to usage – Basecamp, for example, takes more of a commitment to project management. Backpack is the opposite; kindof an anti- project manager. It is a perfect light-weight collaboration tool for us. Agile in its own design, and helping our team be agile by letting us quickly jot and share thoughts and priorities.
posted by
jason
on Wednesday, Oct 04, 2006