I just recently appeared on a panel talking about Agile development, User Experience, the benefits and the pitfalls. It was fun to have a discussion with people from of other thought processes about agile and waterfall, but I’m a huge proponent of doing development and User Experience this way.
My first experience with Agile was April 2001, and I’ve run several projects with it. That original project was as Product Manager for Escrow.com, and we ran iterations for almost a solid year (close to 20 iterations or sprints).
The result? A profitable company with a profitable product.
Three of the projects I worked on went by the wayside (there’s no accounting for issues with company culture), but five others, including Escrow.com, launched successfully and have had varying degrees of business success. Agile doesn’t guarantee a breakthrough product, the hope is that it removes development process as a risk.
This first thing I’m going to do is define Agile development so we’re all on the same page.
Agile methodologies (or cultures), generally have the following:
- Short development cycles of two to four weeks, and are usually called iterations or sprints depending if you’re using Scrum or Extreme Programming.
- Almost daily communication through short meetings (called standup meetings). They report what you are working on yesterday, today, and tomorrow so any issues can be discovered early. The purpose of the meetings is to encourage further communication (these meeting are short: if you’re going over 15 minutes, it’s too long) offline.
- Development progress is measured through what’s called burndown and the product backlog.
- The client or product owner is intimately aware of progress, and prioritizes based on product needs. Everyone has a voice in what the product is.
- The process is adapted to the team, and they own the process so they get to use elements that work for them.
- This is key: everyone is upfront about their responsibilities, and doesn’t hide their roadblocks.
It’s key to note that I used the word “generally” because the process is defined by the teams that use it, so some may only use elements of Agile and Scrum.
I’ve seen Agile work well for products that require constant improvements, but it’s hard to adapt it to a new development unless you have some time to adjust the process while people are learning. Short projects of less than a month make it hard to do a scrum-like process. I can’t imagine using Agile for a hardware-based product.
But for the web where everything is changing, it’s great.
Here’s how to convince most User Experience teams Agile can work:
You get direct access to the developers
One of the major complaints I have about most waterfall environments is that once you write the functional requirements and wireframes, you’re pretty much done. Developers push back, you miss 25 to 30 percent of the requirements because you just didn’t know or no one read your requirements, and there’s always the, “Well, that’s not what I meant” misunderstandings because there was a different interpretation of the wireframes.
I’ve run a Scrum-like process over the phone (doing so for a current project), and the main purpose of the methodologies is to encourage more communication; with daily meetings and constant touching, you usually can walk over to the developer and ask to see the work.
If there’s an issue of the design not working the way you want to, you can negotiate with the developer to build it in a way that achieves everyone’s goals.
While you don’t get to do as much research, you do get is to see your work in action sooner
Since of waiting three months until you see your work turned into real software or website development? This is the process for you. The rub is that most of the time, you’ll get to do two weeks to a month of research at the very most before development wireframes or user stories, and that’s okay, because unless you’re inventing the new iPhone, why would you want to do that?
Usually you develop a lot of areas with stubs (i.e. we’ll do that later, but just put a page there), and concentrate on the big functionality. Your initial stab at what to build is called sprint or iteration zero, and in most environments you’ll stay one iteration ahead of the developers. This gives you a little time to move and adapt, and in some ways, it doesn’t allow you to over think a feature.
From Agile Product Design:
User experience people working on Agile teams become masters of development time travel nimbly moving back and forth through past, present, and future development work.
You’ll see your work as they build it, and you’ll also spot issues in days instead of weeks.
Agile doesn’t mean no requirements, it means requirements that work for the team
Since the team gets to decide how to build the process, that means the requirements can take whatever form you want them to take. If you can’t do wireframes or HTML mockups that fast (I can), then this process will be a tough learning curve. However, one of the panelists had a great idea: go to another website that has approximate functionality and copy it (seriously, how many times do we need to redesign a lost password process?).
I’m a big proponent of the whiteboard or throwing the wireframes up on the wall in printed format– talking through a feature instead of looking at it in a PDF is a much more effective way of communication.
To mitigate direction issues, I did was develop a really high level style guide to make sure we had a holistic view of the system, and then did not annotate wireframes. The developers knew just the form or text elements, and if they had a question about functionality, either they asked about it in the stand up meeting or contacted me separately. Occasionally, I was diving into the code myself to write error messaging, which was okay.
Sometimes, it’s not what you communicate but what you don’t have to communicate that makes all the difference in the world.
If there was particular communication that we felt wasn’t needed, we would cut it out of the process. (Who reads all the requirements, anyways? Usually just the User Experience folks while arguing with the developers.) That’s an important distinction, because if management is forcing something down on the team, Agile isn’t going to work. It’s not about the tools, it’s about the people using them.
If your initial pass doesn’t work, it’s not stuck in the final product
While there’s not a lot of time for formal testing, there’s plenty of time for guerrilla usability testing: that means you have to bring in or find some test subjects to throw against your ideas. This doesn’t mean writing formal reports — there’s not enough time for that — but it does mean doing enough testing to make sure your product is going the right direction. You won’t spot every issue, but it’s about rocks and sand: you’ll catch the rocks, and have to worry about the sand later.
It allows you to fail quicker: if there’s something you spot that’s really, really off-base, you can propose to fix it in the next iteration.
The other members of the team may agree. I’ve pulled features in previous environments without serious implications, and all we lost was a week’s (or less) worth of work.
Smart agile teams also pair user experience designers with quality assurance analysts to write test plans for test-driven development: developers would recieve test cases even before they started development so they knew what they were aiming it. This is great, because QA is one of the best groups of people to do usability testing on: they spot potential issues even before the developers do.
On a few projects I’ve been on, we’ve seen a 50 percent drop in defects reported, and had fewer reworked features.
That’s huge.
You can see progress almost immediately
One of the biggest frustrations of working in software development is the period of waiting for something to be built. Agile takes away some of that frustration because instead of developers waiting until the last three weeks of a three month project to show the results, delivered features are agreed upon after the first iteration.
This creates this sort of washing machine effect to requirements gathering and software development. You keep on moving to a common goal of building the final product; instead of seeing huge leaps of functionality (with possible huge leaps in missing the target), tasks are built in bite-sized chunks so you have a better idea of meeting your goal. Because of this, you also get idea of if your estimates for building the product are on base, and what you have to adjust before
It’s about making it to the finish line, one inch at a time.
The 80-hour workweeks are gone, sort of
One of the rules we had at Escrow.com is that no one worked over 45 hours a week, and if they did, I kicked them out of the office. Two similar projects I worked on, we had the same approach.
This was very important from a few standpoints:
- Developers and User Experience designers without a life are angry people
- Tired developers are ineffective developers
- Estimates only are effective if there’s a decent control mechanism
The main benefit was getting a true gauge of process. How many have been on projects where the developers worked slowly until the last month, then crammed a bunch of hours in to the get to the finish line? And how good was that product, really?
Doing good estimates is essential to Scrum and Agile, because then you can accurately decide what’s important and what’s not.
At BidRx, only after we attached Scrum did we get an accurate assessment of what was possible from a User Experience and Development standpoint in a sprint.
That means that developers and user experience designers have to have a good idea of what they can produce within the framework of a normal workweek. Being wrong the first couple of sprints is fine, as long as you can get closer each time. Remember, it’s about attaching iterations to the process as well as the product.
Your voice is heard, period
One of the greatest things about agile development is that everyone has a voice; that means that if there’s something you don’t like in the process or the application you are building, you can express your opinion instead of being on the other side of the wall from the developers.
There’s always a user advocate in the process of building the product.
The conculsion
Agile isn’t for everyone, but when it does work, it works well. But it does require a different mindset, and there are flaws to overcome.
Random Thoughts mentions the following downfalls:
- Lose the holistic view of the system
- No time to prototype everything before development starts
- Lack of extensive requirements
- More development teams working simultaneously, same UX resources
- Fast delivery means less time for testing and iteration
- Loss of time for user research projects and general research and development
- A need to track UX worth and work before a project is completed
I only agree with the two that are in bold. That said, we have to try something different, because waterfall isn’t working.
Some other links:
Blog posts:
![]()
