This is part one of a 12 part series about an update to the Agile Manifesto.
In early June 2021, Jesse James Garrett, a pioneer of User Experience, wrote an article for Fast Company lamenting the erosion of user-centered and insight-driven design as UX becomes more of a commodity and less of a discipline:
Too many UX leaders have seen the field’s language and ideas co-opted and corrupted by outsiders who never knew or cared about the principles underlying the practices… businesses cherry-picked the bits of UX most compatible with their existing agendas and eschewed the parts that might lead to uncomfortable questions that could influence more than the color of a button on a screen.
One such agenda is that of “agile transformation,” which promises to remake organizations to optimize their processes for developer efficiency. This is a win… for businesses trying to wring maximum productivity out of their growing armies of engineers. However, in the rush toward transformation, something has been lost.
What got lost along the way was a view of UX as something deeper and more significant than a step in the software delivery pipeline: an approach that grounds product design in a broad contextual understanding of the problem and goes beyond the line-item requirements of individual components. Also lost along the way were many of the more holistic and exploratory practices that enabled UX to deliver that kind of foundational value.
The Agile method that Garrett speaks of was codified in 2001, and it has fallen prey to problems which I believe are due to some gaps in the original set of principles set down at its founding. Since Agile has become a touchstone for digital development teams, and since it will likely be around for a long time, it is worthwhile to look at reinvesting Agile with user-centered and insight-based values that foster good UX.
The 12 Principles of The Agile Manifesto
The Agile Manifesto was written by developers from different companies with different clients and goals. With so much variety, there was a lot left out of the final text since there were many points of difference among the members. As a result, the 12 Principles are broad and keep only those ideas that were agreed upon by all of the writers.
Time For an Update
Agile is well worth using by those who build websites, but there are some gaps in the original text which can be confusing. There are several important questions that need to be dealt with and changes that need to be made to make a useful set of guidelines for customer experience.In this article, I have taken each of the 12 principles and updated them to be more clear and easy to use. I call the new set called “12 Agile CX Principles.” This update is mainly for website teams. The changes make it a better tool for other teams that are using or are thinking of using the Agile method.
Principle 1: The Highest Priority
In the first place in the Agile Manifesto’s 12 Principles, the first Principle tries to give the main reason why we do development:
The highest aim is to understand and serve both the customer and end users by making websites that have great worth. We do this through quality development, rapid delivery and continuous improvement.
These words are a rallying cry for teams to keep their eyes on the customer and deliver for their sake early and often. It also makes teams who truly embrace Agile look good: it celebrates team spirit, an esprit de corps not usually seen in other places in the business world.
However, not all teams fully embrace this principle. This may be because it fails to make some things clear, and does not acknowledge the business matters that affect what is important in practice.
The Customer
The first question we find is: just who is “the customer?” If the Agile team is doing contract work, then they are developing for “the customer.”
This omits the end user. There are only two ways this can be:
- If the group of people that hired the team is “the customer,” then there is no thought given for the needs of any end-users. The thought is either that “the customer” will account for all of the users’ needs, no questions asked, or that it simply doesn’t matter.
- On the other hand, if “the customer” refers to anyone that touches the product, then the people paying for the website, the end users, and anyone else (third-party vendors, partners) are all grouped together as a whole.
Either way, this Agile principle does not help us think of the end user. This is odd, since many people who love Agile also love User Centered Design.
This may come as a shock to some who believe that these two – Agile and User Centered Design – are the building blocks of their development work. And that is what is so tricky about catching this oversight.
If Agile teams simply think that user needs are already in hand, and the client is sure that it knows best, then we are in a kind of Orwellian world. On the outside, everyone thinks they are working for the good of “the user,” while inside the workings of they development no one bothers to find out who “the user” really is.
Ignorance is Strength.
Users Are Who We Say They Are.
The “User”
In his groundbreaking 1999 book The Inmates Are Running the Asylum, developer and author Alan Cooper saw the danger of abusing the term “the user.”
Cooper notes that since developers often use the word loosely, they are really thinking of an “elastic user” that can stretch unnaturally on a whim. The problem is that real users, that is, real people, do not stretch like this.
Instead, it may be that the client does have the users’ needs well in hand. The client may have excellent customer service, a lot of research, customer surveys, and in-depth user testing. However, no one may be taking the extra step to share this knowledge across the table to help better mark out the users’ needs as distinct from the client’s needs.
This turns up another problem: how are we keeping the end users’ needs separate from the client’s business needs? There may be areas where true users’ needs are overlooked, and that can lead to them having poor feelings about the website. Tthis can lead users to ask for updates and fixes, but there may not even be the means for clients to hear and serve these needs. This means we are failing to cover an area that is doubly important – where the users ask for updates that make the product better, building value both for the end users and for the client.
Priorities
Understanding the difference between the needs of the end users and the needs of the client may also change how decisions are made that affect how the client looks. Those places where user needs and client needs don’t quite meet can affect ethical or even legal matters. Without acknowledging this difference between user and client, these issues can arise through bending the rules or through abuse. The “highest priority” must be judged with these things in mind.
Even if Principle 1 is updated with the users’ needs as well as the client’s, it is still too much to say that any one thing is the highest priority. It may not always be up to developers to claim this level of authority. Other team members may cause friction when their needs cannot be met.
Other Questions
No one can say with certainty what to do about other things that will vary from project to project. We must answer some questions on a case-by-case basis to make Agile practical for any website project:
What is the website worth to the client? How is it measured?
The worth of the website can often be measured in terms of traffic, interaction, engagement, and return on investment (ROI). We can measure it using a number of tools, many of which are part of online campaign platforms. A joint effort with the development team and the client must make these decisions.
How is client happiness defined? How is it measured?
We can link client happiness to meeting goals set for any of the values above. Also, there may be surveys and feedback gathered from the client team separately from the broader user data. We do this in order to better understand both groups without mistaking one for the other.
What is the website worth to the end user? How is it measured?
The worth for the end user may vary greatly among different types of websites, such as eCommerce, corporate, informational, etc. We should include direct engagement with end users by means of surveys, user testing, customer service requests and so on. These add up to more of a complete picture, in numbers and quality, of the worth of the website to the users.
How do we define end user happiness? How is it measured?
As with the client happiness, we measure by setting targets for counting the worth for the end users. Since end users vote with their dollars, we must also think of sales. We should also bring sales data into the picture of end user happiness.
Early and Continuous
What do “early” and “continuous” mean in terms of the scope and schedule of work?
Early delivery sounds wonderful. It should be part of the team spirit we saw above. In many companies, it shows the team’s dedication to the project. Many teams pride themselves on beating, not just meeting deadlines.
However, we should understand that “early” should not mean “premature.” Larry Tesler’s Law of the Conservation of Complexity states that for any system, there is a minimum amount of complexity which cannot be reduced. In effect, launching too early can lead to a breakdown of the project. If the backlog of fixes overwhelms the further development that was planned right after launch, then it will sabotage “continuous” delivery. Projects that are too quick out of the gate may actually slow things down to a point that momentum cannot be recovered.
It is good to be optimistic about being “early” and “continuous,” but we should also make sure we are doing enough to make a good product.
Here is the updated version, now Agile Web Development Principle 1:
The highest aim is to understand and serve both the customer and end users by making websites that have great worth. We do this through quality development, rapid delivery and continuous improvement.
GET THE BOOK
Proven methods.
Better results.
Over 400 pages of insights and step-by-step methods for planning, designing, and testing your website.