Agile development has recently captured the imagination of many software development teams—and with good reason: its focus on producing working software quickly is well suited to today’s fast-paced markets. But how do you go about combining agile with user-centered design (UCD) so you can enjoy the benefits of both approaches? On the face of it, they should work well together because both philosophies are iterative, incorporating testing with users and refinement. But in practice, they often conflict with one another.
An agile approach such as Scrum tries to minimize up-front planning in favor of producing working code quickly. Plus, agile generally prefers in-situ workshops for gathering requirements, while UCD largely favors up-front user research. Agile also uses working software as its primary measure of progress, while UCD focuses on whether users can easily achieve their goals—with or without software. To add to these discrepancies, because agile is typically led by developers, while UX professionals usually drive UCD, the differences between these two approaches can result in political conflicts in many companies. Read More
Whether you’re doing business development for an agency or an in-house UX group, to win a stakeholder’s business, you must provide a value proposition that makes your services more attractive than those of your competitors. If you’re managing a project, a team, or a business that depends on the delivery of services, it’s essential that you negotiate the project scope and ensure your stakeholders understand what you’ll be delivering before beginning work. It’s also important to reconcile the project scope and track status along the way and to manage costs and stakeholder expectations—not to mention your contractual obligations.
In this article, I’ll describe the approach that I devised for scoping, estimating, and reconciling services at Phase II, an external agency, and have since applied as an internal service provider at Intel and The Home Depot. The scoping and estimating spreadsheet that I created has evolved over the years and now accounts for a far broader range of services than it did initially. My work, whether at Phase II or as an internal service provider has always focused on B2B (Business to Business) applications—meaning I am serving clients who have clients of their own. This is an important perspective to keep in mind. In a B2B context, your clients need to know the costs of services they’ll incur as quickly and transparently as possible, so they can, in turn, manage their change orders with their client. Read More
If you use—or want to start using—an agile-development process, you probably already know its benefits, but you might not be as aware of one of its main drawbacks. Even though 46% of US organizations and 85% internationally report that they’ve used an agile approach within the past year, communicating your agile process to clients remains a challenge.
Specifically, the problem is bridging the gap between clients’ expectations of the process and the way agile really works. But overcoming this difficulty is well worth the effort if you wind up with a first-rate product and a fully satisfied client.
Of course, some clients are already quite familiar with how agile works. However, for those who aren’t—and whose previous experience was with waterfall product-development approaches—explaining the process and merits of agile can be tough. Sure, your clients might know some agile buzzwords, be familiar with some of the tools, or know the importance of meetings to the agile process. However, it’s unlikely that they understand how agile actually works in practice. Read More