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.
 |
| 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 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]
"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:
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.
- 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]
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.
 |
| 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:
[2] UX In an Agile World:
http://www.nngroup.com/articles/doing-ux-agile-world/
[3] The UX Problem:
https://boagworld.com/design/the-problem-with-agile/
[5]
UX SAFe 4.0: http://www.scaledagileframework.com/ux/
[6]
UX Guide: http://boxesandarrows.com/the-ux-professionals-guide-to-working-with-agile-scrum-teams/
[7]
Don’t do agile, be agile:
http://sdtimes.com/dont-do-agile-be-agile/
[9]
So Agile Together: http://uxmag.com/articles/so-agile-together
[10]
Agile
Poster:
https://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html
https://agiledogma.blogspot.co.uk/2014/04/agile-development-poster-there-are.html
[11] Agile UX Sprint:
No comments:
Post a Comment