Agile in Theory
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “ – Twelve Principles of Agile Software
I have never understood the supposed incompatibility between Agile Development and User Experience (UX) Design.
The Agile Manifesto and the Twelve Principles of Agile Software read as a pointed challenge and open invitation —directed at UX— to shed the excessive weight of historical process and over-design and enter the modern world of software development. It reminds us —and we need reminding— that getting known value out to users quickly is good user experience; that starting with simplicity and iterating is the key to managing complexity; and that it is the UXD’s role to insist upon clarity, economy, and thoughtfulness at every step of the way.
Good UX is Agile. Good UX is LEAN. Good UX is placing known benefit into user’s hands as economically and efficiently as possible. Keeping users waiting is not improving their experience.
Agile in Practice
In practice, introducing Agile to our development process empowered us to create great product, far more efficiently and effectively than Waterfall ever did. However, I must admit that it has been a bumpy road. When we introduced Agile, we turned to Scrum to provide a framework. Years of reflection and adjustments passed and —while we are thankful that the days of Waterfall project management were only recalled with knowing smirks and lingering gulps of beer— a festering frustration with Agile continued to mount.
- Varying expectations. Expectations around “done-ness” of tasks, sprint goals, and release candidates unfailingly varied across the team (QA, Project Managers, Engineers, and Design).
- Constantly moving target. Engineers and QA felt that they were always aiming for a moving target, even heading into a release.
- Lack of holistic design. Under pressure to focus on one story (or feature) at a time, Design never felt able to think holistically about the product.
- Velocity tracking is confusing. Tracking velocity never provided truly meaningful or useful data, instead serving as a source of miscommunication and all-round frustration.
These are serious concerns and they had a visceral effect on our working environment. Frustration, stress, disenchantment, and blame simmered in the background. Project teams reflected and adjusted process and behavior in knee-jerk reactions, further exacerbating the problems. The wake-up call was when colleagues started forgetting the hard, past lessons learned and suggested waterfall-ish changes, such as introducing a Design-only Sprint 0 and regressing to weighty documentation.
Time for a solution.
Roughly 9 months ago, a small team of us were about to embark on a new effort (rebuilding a grade submission app). Everyone was coming off some grueling projects and low morale soured most interactions. No one wanted to continue working in the environment as it was and Agile was being dismissed as a failure.
At this point, things felt so broken that trying to get things back on track while still actively developing wouldn’t work. So, we decided to take 2 weeks to focus on finding a few solutions. Taking this on as a user experience problem, we started by identifying the project management needs of the team and set out to design a solution to meet these needs.
It turned out that these 2 weeks were well spent, as we nailed an Agile project management framework (Iterative Fidelity Development) that has proved successful on a wide variety of projects and has helped us refine our UXD process to align our User-Centered Design (UCD), LEAN and Agile principles.
Do these problems sound familiar? Leave a comment below to continue the discussion.
There are two additional posts in this series:
Part II highlights our realizations that led to the Iterative Fidelity Development framework.
Part III offers a high-level overview of the Iterative Fidelity Development framework.