The 80:20 rule of Agile and UCD
I want to tackle the intersection of User-Centred Design (UCD) and Agile. I’ll start by saying I am fundamentally not an Agile detractor. I respect and appreciate the need for process to help shape and deliver complex projects.
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.
I think that we have to be pragmatic about what can be achieved in the Agile environment and need to encourage the business to understand the risks involved in letting it become a fully technology-led approach.
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.
Project Management
If User Experience from its infancy to now has figured into the last 17 years of my career, project management at all levels has figured into my entire career.
Starting out as an Engineer 24 years ago, I provided the project management on all of my projects. When I moved into digital in 1994 I project managed much of the work that I performed, and the teams I was involved with.
I have done everything from act as a sole project manager to work at Management team and Director level overseeing project management and operations. Nearly 10 years ago I took on the role of Head of Project Management at Zentropy Partners (now MRM Meteorite), and over the last 10 years have provided a mix of Project Management and User Experience services for my clients.
I understand the time-scope-budget triangle, have worked in Waterfall and Agile environments, and get the importance of User-Centred Design. In nearly all of my roles I have worked at the nexus of technology, internal stakeholders and customers.
I’m good at working with and understanding the needs of teams. I’m personally very organised and am really passionate about employing my diverse, but relevant, experience to projects and teams.
Think of me as an organised but creative thinking project management professional who can work at Director level.
BBC & BBC Worldwide
Over the last five years I’ve had the pleasure of working with the BBC on a number of occasions. These included when I was Managing Director of phunQube and we worked on Top Gear and Lonely Planet. In the Top Gear project my team and I worked on everything from requirements capture and prioritisation, to UX Strategy and Tactical UX.
I later contracted for the BBC through Digital Optimist on the Digital Media Initiative (DMI) program where I was Head of User Experience. I built a team from the ground up and ran teams in Agile and Waterfall environments on the development of a digital television production platform, the BBC digital archive and rights management system.
The project continues to roll out in stages and has a long term vision to replace several legacy systems and become the digital work platform for the BBC, supporting its move to Salford and other regional locations.
