This post was written by Jonathan Baker-Bates, a UX designer at Hotels.com – @gilgongo
I’m a designer managing the user experience team here at Hotels.com, where we’re always trying to improve the way we work. It’s a tricky job, because regardless of the organization you’re in, no two UX projects are alike. That’s why the best design teams are the ones that can call upon a wide variety of techniques. A large part of a designer’s skill is knowing which techniques to apply to which projects in order to solve design problems. Designers need the freedom to do this – the freedom to do the right thing.
We define our team’s success in terms of getting ideas to market faster than the competition and executing those ideas better for customers than the competition can. I believe the success of any given method to do this depends mostly, if not entirely, on the environment in which it is practiced. I don’t think it depends on whether you’re PRINCE2 compliant, if you have great documentation, or if your time sheets are up to date – and nothing will work if your people are unhappy.
Regardless of the environment, you still must apply a framework that allows the best methods to emerge for your operation. For us, Lean Kanban is that framework, and the best tool to enable it is AgileZen, and here’s why:
First, some background. Hotels.com is a large and very complex e-commerce operation. Well over 200 people work in core operations here in central London, with hundreds of others based around the world. We have 85 web sites in 34 languages, and list more than 145,000 hotels in 19,000 locations. We’re big. We know we don’t deliver the best user experience for booking hotel rooms, but we’re trying to improve that.
My team receives business ideas from the Product Team, and works with them on how to execute those ideas. There are another seven Creative Designers who go on to interpret those executions to suit our brand. My team looks after the customers’ heads, while the Creative Designers look after their hearts.
Over the past four years, we’ve tried various methods of working, including home-brew variations of waterfall and Scrum (you can read about our experience here). Kanban works best for us for two reasons:
- Enabling us to work on projects in whatever manner we choose. There are no sprints, no estimation, no burn-down charts or time sheets. Stakeholders are welcome to specify deadlines for work but rarely do. Instead, we focus on average cycle times. If an estimate of delivery date is needed, those cycle times can be used to plan accordingly. We have no project managers, because they would have nothing to do.
- Kanban helps us go faster. The process shows the entire team how much “waste” we generate. Waste takes two forms: time wasted when jobs are blocked or waiting for feedback, and time wasted when jobs are waiting on the board for somebody to commence work. We assume that if it is not waste, it is productive work.
Further, we impose a work-in-progress (WIP) limit guideline. Project team members must not work on more than two jobs at once, thereby keeping the project flow quick and efficient.
Our basic metric is the amount of waste. Compared to hours worked or number of jobs complete, it is clearly actionable information. We reduce waste through experimentation: sitting people closer together, attempts at pair designing, cutting out process stages, etc.
The main focus of attention during our projects’ life cycle is our physical Kanban board. The power behind the board’s throne is AgileZen. When we started with Kanban, we ditched Jira, the tool we had been using until that point. We found most digital tools to be overly cumbersome, time consuming, and an end in themselves. Our team hated Jira because of this. AgileZen became our new solution to make our system work.
AgileZen is a joy to use. We’re designers, so the visual nature of a product counts for a great deal. The API gives us potential for flexibility, and unlike other systems, those parts of it we don’t use stay politely out of our way. Crucially, AgileZen’s project management system makes tracking our work and waste very easy. Every day, we have a team stand-up at which the facilitator simply reads jobs and statuses from the AgileZen screen. We keep the tool in sync with our physical board, which is all about team communication.
Designers are not typically process-oriented people. We want something that fits silently in to the way we want to work. AgileZen does just that and is worthy of its name.
If you have questions about how we’re using AgileZen, it would be great to hear from you in the comments.