Saturday, 27 February 2016

Agile UX Is a Misnomer


Scope:
The UX community seems to struggle with Agile. They seem to want a special approach called Agile UX to resolve this struggle. As this quote states:
"Agile UX describes update of Agile Software Methodology with UX Design methods." [1]
I am not sure how such a wild statement of being able to 'update' Agile can be true and this article will show that there is no such thing. Agile UX is a misnomer.

UX User Experiance
User Experience

Problem:
From the many articles on the web UX professionals seem to be historically Waterfall people in their mindset. Which is why they struggle with Agile.

A classic example of this is whereby the UX practitioner works outside the team performing research (analysis) and design outside of the teams inspect and adapt feedback loop.

"UX Must Work at Least One Step Ahead of the Sprint" [2]

Not within the Sprint as part of the Agile team. Also retrospectives with the team seem not to be practiced within the UX community. This is akin more to mini-waterfall than Agile.

UX Sprint
UX creates Mini-Waterfall [11]
Others in the UX community want to 'game' Agile because it does not fit their work practice.
"For example, how can you test information architecture without all content areas in place?" [3]
In the above scenario presented, rather than use mock-ups or deliver separately parts of the feature value content, all must be built before anything can be tested. Thus rather than deliver customer value, the goal is changed (gamed) to that which suits the UX person rather than the customer/user. And so, it continues:

"sprint 1 might be a paper mockup of the entire minimal viable product. Sprint 2 might be a high fidelity wireframe and sprint 3 the final build." [3]
So, we are back to phased delivery and Waterfall again rather than producing features the customer can use and get value from after the first Sprint. 

It can get worse than this. Whereby UX experts even take iteration commitment away from the delivery teams. Often trotting out excuses such as not enough UX people as within this article [4]. Yet as can you see from the article, somehow once they are away from the rest of the Agile team they manage to resolve this issue still with the same number of people.

"large planning sessions with all POs present is because it lets us set priorities as a group" [4]
Surprisingly the comment above is only for the UX and PO's backlogs and not the team. They are not planning with the Agile teams. So, once they are done, someone will still have to place it back on the real-backlog for the Agile team to re-prioritise for delivery. Unless of course they are forced to take it on which is even worse. The comments on that page speak volumes as well about separation from the Agile team.

On many of the well known UX websites there is article after article on this subject. The solution it seems is to have an additional specialism to UX called Agile UX. This way UX skilled professionals can fit the Agile approach into their experiences and skills. Hence the constant stream of statements of working around Agile.

The role has even appears in SAFe as a specialist role in itself. Yet other roles that are in the Agile Team within SAFe do not get this special treatment [5].

A more comprehensive study alludes to the problems UX professionals have with Agile. Let us look at this article and the problems UX people 'think' they have with Agile [6].
"The opinion that ‘This is good enough.’ Design implementation always goes to the bottom of the priority for the sake of MVP… Pushed to the next release and stay in the UX bug list forever." [6]
Of course this is not the UX designers call and it is up to the Product Owner. But the UX professional does not see it this way. Their design is somehow more important than the MVP!
"No time is considered for design of the overall framework. Scrum teams jump into feature releases. They’re building inside out instead of outside in or holistically." [6]

Teams can build architecture holistically, therefore they can do this with UX too. You have to convince them like you would any stake-holder. Join the team.
"Design needs to align earlier and sooner with the business owners to ideate and come up with a great design." [6]
Indeed it does just like any design delivery that any Agile team has to work upon. Being outside the team causes this problem.
"Developers build whatever UI they think is appropriate while a designer is working on design iteration or testing." [6]
This happens when the UX person is not part of the team. People will work separately if they are working in silo's.
“developer-centric culture” [6]
Agreed and is just as bad as a UX-centric culture. Avoid both as neither are Agile.
Then these three final quotes are all the same:

  • Sometimes engineers are thinking of the solution without understanding the need.
  • The challenge is that supporting two teams that are both on nearly identical timelines
  • Difficulty in being aligned with the engineering team which is mostly in India. [6]
The above are not UX specific problems. Even if this were a back-end messaging system, these would still be problems. UX is nothing to do with the above. Yet cited as UX specific problems with Agile by the article.
When we get to the real route cause it is this.
Once you state that your skill-set must have an Agile diversification to it, you saying it is a technical specialism in itself.
Agile is a method and approach in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.

For example a Java Developer codes in Java. If they are Agile they do not code in Agile Java as there is no such specialism. They are still a Java Developer but one that also is Agile. Thus a UX Designer does not become an Agile UX Designer as there is no specialism as Agile UX.

Agile UX is therefore a Misnomer.

Solution:
Rather than professionals add UX Agile into their work, the solution is that they be Agile. As the old Agile saying goes:
"Don't do Agile, be Agile" [7]
If you just 'do' Agile, this means you sometimes do it and other times you do not as opposed to 'be'ing Agile in your approach to all of your work regardless of skill set. Either you be Agile or you be not. There is no partial credit for half-Done in Agile.

Once UX professionals be Agile, they should also be a part of the team. As important as any other member of the team and just as special. But not separate from the team. They should be in the team as a fully fledged full time dedicated team member. You cannot be in the team if you are also part of another team or area. No part-timers.

Indeed as one person added a comment to the article that sums it up better than I ever could:
"We have had our UX resources embedded in the scrum teams for the past 4 years. They are as much accountable for forward development work as a java developer or a DBA or a BA or a test engineer. UX related tasks are are added to user stories accordingly, we don’t have separate stories for UX. IMO, keeping UX away from normal development sprints is risky and probably not agile. Same with technical documentation, a story isn’t “done” if it still needs UX work (or documentation work) at the end of a sprint. Seek to minimize hand-offs and the pain points will ease." [6]
Tangible solutions of this exist and from within the UX Community itself. This article despite the title has a community solution [8] when scaling and here as part of the team [9].

Indeed in SAFE 4.0 maybe Dean should consider removing the specialism on his Big Picture. As SAFe 4.0 itself when you dig into the detail he has conceded that the UX person must be a part of the team. Which is the way it should be. As can be seen here in this SAFe 4.0 sub-diagram.
SAFe Scaled Agile Framework 4.0
UX as part of the team in SAFE 4.0
Agile Link:
This article is not to devalue UX at all. This is proven by the entry on my Agile poster whereby UX Design has always be listed as an activity long before this article was written. [10]. In fact it is to show that while Agile UX is a misnomer this is only because UX activity is encompassed as a part of Agile deliveries rather than in separation of it.

References:
[7] Don’t do agile, be agile: http://sdtimes.com/dont-do-agile-be-agile/
[11] Agile UX Sprint:

Posted by at No comments:
Subscribe to: Posts (Atom)