The 80:20 rule of Agile and UCD

When it comes to UCD I am a strong believer in designing the ‘right’ thing for the ‘right’ user – of course, I also strongly believe the most successful UCD projects find a good balance between the needs of the user and the business.

In my experience, whether intended or not, Agile has typically promoted the technology team to the front of the pack, with the consequence of producing the product through the eyes of a team focused on what it can do in the time (Sprint) and with the team (capabilities) to hand.

The needs of the user and the business as a whole are minimised and the view of the overall product becomes lost. In fact, instead of a product comprised of functionality and workflow, it becomes functionality and workflow that define a product – and one that you may never have intended to build.

With a rule of thumb of 20% of the product design done in advance and 80% done within the Sprint, highly complex projects run the risk of delivering functionality that meets the needs of the stories but not the final needs of the product, business or users.

I believe that in the rush to kill Waterfall and move to Agile – ostensibly so businesses could deliver incremental functionality to their users – we threw out the baby with the bath water. At a time when the competing methodology of UCD was gaining traction and helping give shape to digital products and software, and a stronger voice to the business and users, the zealous deployment of Agile derailed the process and the product.

The end result is a process that is driven to deliver – but what?

I think that we need to regain balance in the system. The pendulum has swung from using a methodology (Waterfall) that people felt took too long to get to a deliverable, to one (Agile) that gets there quickly and incrementally, but may never give us the product we wanted.

I think we need to consider 3 things:

1. Is the project itself about an incremental addition to an existing site or application, or is it a small to mid-sized piece of development?

Knowing the answer to this will help determine whether the 80:20 rule is relevant, as the more complexity is involved, the more time must be allocated to up front requirements and product design – perhaps making the split as much as 50:50.

This helps determine whether you dedicate the bulk of your product design resource to the Sprints, or you require an advance team that provides an overall shape to the product allowing those working in the Sprint to provide the detail.

2. Where are the users and stakeholders in the process?

There needs to be a clear plan that incorporates stakeholder reviews and user testing. There should be real user testing on prototypes or development sites prior to any releases, with enough time planned into the process to make real changes – and test again if necessary.

All too often this is lopped off, along with any thoughts of making the applications accessible due to lack of time to develop. Stories to fix designs languish in the backlog and never see the light of day and the end product delivers something – but is not the piece of brilliance it could have been.

In fact it might not even be fit for purpose.

3. Are you designing with the thought that there will be ample opportunity in future Sprints to make changes?

We’ve all gotten stung by this one. Consider the very real possibility that what you are developing now may well be the final product. As a UX person, fight your corner to get the most out of the process to ensure that users and the business can live with what will be deployed.

Don’t allow anyone to compromise this and don’t believe that the backlog will one day magically equal zero and all stories will become reality.

It is meant to be a methodology for delivery. Ensure product design is represented in early discussions about the project and in the plan and that we don’t mystify it to the point of becoming marginalised in the process.

I’d love to hear your experiences.