SAFe Agile Framework is Wrong About UX
Have you seen that the SAFe Agile people are empowering non-UX roles to do UX work in their latest version?
The page starts with this quote:
“What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?” — Eric Ries
Yes, that’s so true. It’s part of what lead me to develop the “Dev && UX” training. Too many software development teams (regardless of methodology) are excluding, circumventing, and disrespecting UX. UX are the expert product designers and include research on what customers really want. Execution is more important than the idea.
So yes, Eric Ries, plus DevOps has “building the right product for the customer” as a goal. Aren’t we all on the same page?
SAFe wants to get rid of UX specialists and give UX work to “Agile Teams.”
SAFe’s Lean UX page tells you that traditionally, UX work was done by specialists but often without collaborating with engineering. SAFe complains that UX work was often “siloed” from engineering. Yes, that may be true and yes, UX should collaborate more with engineering when designing.
However, instead of taking the approach of, “UX should collaborate better with engineering and here’s how,” as our training covers, SAFe instead misinterprets a quote from the Lean UX book:
”Lean UX literally has no time for heroes. The entire concept of design as hypothesis immediately dethrones notions of heroism; as a designer, you must expect that many of your ideas will fail in testing. Heroes don’t admit failure. But Lean UX designers embrace it as part of the process.”
As a UX specialist, I know what that quote means. That means there is no ego in UX design. Don’t fall in love with your designs. Don’t manipulate testing or results if your idea fails. Learn from failures, iterate, and design something better. Remove the ego.
Sadly, SAFe appears to imagine that “no heroes” means “no specialists required.”
SAFe empowers Agile teams to do UX work, claiming this is what’s needed to move away from the “siloed specialist approach” to a more “collaborative, cross-functional design model.” I’m not sure how they validate this hypothesis.
- Magically, UX is the problem and has to change. Not engineering. Not truly collaborating and finding change from both teams.
- Engineering specialists are great to hire. You want specialist developers and expert QA. But UX? Do we really need these specialists?Somehow, we do not.
- Interesting that their definition of collaboration is to remove tasks from specialists to give them to non-specialists.
Collaborate with everybody except UX.
SAFe recommends “including the design perspectives of Product Management, System Architecture, Business Owners, information security, operations, and Shared Services.”
That means we’ve gone from having UX do all of the product design to having UX do none of it. They’re not even included in this list of roles with which you should collaborate. Include the design perspectives of everybody at the company except the expert product designers.
SAFe purposefully minimizes expert UX practitioners.
SAFe’s Lean UX page also says that UX specialists have an eye for design, a “feel” for user interaction, and specialty training. To say that a specialist has a “feel” for his or her area of expertise is designed to minimize that person. You wouldn’t say an expert cardiologist has a “feel” for working with the human heart. You wouldn’t say your senior developer has a “feel” for working with programming languages.
The choice of words is likely deliberate based on where they go from there. And also to help Agile team members feel like if they have a “feel” for user interaction, they can get by without specialty training and just go for it! Of course, in our workshop, we cover why even a UX bootcamp isn’t enough to do UX work. SAFe is confident you can jump in with no training at all.
This shows a continued lack of understanding of UX.
I took days of SAFe training with them in Colorado in 2014. I kept asking where UX fits into this. They told me that they had not yet figured out where UX fits in, and I quote, “If you figure it out, tell us.” Well, I am telling them that they are going in the wrong direction. Will they listen? I hope so.
Agile training previously didn’t include UX. This lead to companies assuming it was unimportant and can be left out or circumvented. Now, this version will tell Agile teams sure, do it, but do it yourself. Avoid product design specialists and experts. You’re empowered to design and test yourself. Agile teams can do UX (and evidently have time for it).
SAFe claims that letting Agile teams do their own UX will improve “business outcomes.”
And what proof of that do they have? That would be true only if the business is looking at time to market. You will release a product faster if you don’t put real time or expertise into UX research, design, testing, and iteration.
But let’s take a look at other desired DevOps results:
- Building the right product for the customer is typically determined by a collaboration between Product and UX. UX is typically the main advocate for the customer’s needs, motivations, and natural behaviors. Remove UX from this and you are moving farther away from building the right product for the customer.
- Team efficiency should decrease when you are asking Agile teams to do work outside of their job descriptions, work they might not be naturally talented at. Dumping product design on the Agile team and excluding UX specialists should lead to teams with less time to do what they were hired to do: develop, QA test, or other engineering role. The Agile Team trying to take on Lean UX is going to have less time for their story points, you know, the work they were hired to do.
- Corporate culture and communication will be a downgrade with SAFe v4.5. What will the corporate culture be like when engineering teams go from misunderstanding UX and circumventing the designs they receive to mostly or wholly excluding them… because SAFe training materials say so? The solution to previously poor communication is not no communication and the exclusion of important, expert, well-trained teammates.
- Shorter time between fixes is an interesting one. If you keep time between fixes short but you have more fixes because the UX is poor or your Agile team keeps changing their mind, did you achieve this goal or not?
SAFe’s page about Lean UX references Personas. Do they imagine that Agile teams did user interviews and came up with Personas? Or do they imagine that it’s OK to use UX specialists there?
Did someone at SAFe have a bad romantic breakup with a UX specialist and this is the revenge?
This is just bizarre. We went from, “UX specialists are trained experts who were too siloed and not collaborating enough,” to “Agile teams can do UX tasks without UX practitioners. But make sure to collaborate with Product Management, System Architecture, Business Owners, information security, operations, and Shared Services (but not UX).”
It’s surreal to see anybody advocating FOR Lean UX but AGAINST UX specialists doing Lean UX tasks.
You want, you need to improve software dev results. The company with the happy customers is the winning company. If you don’t build what customers really want and need, and if you don’t build it in a way that “just works” in an intuitive way, you can fail. Good ideas can fail when executed poorly. This points at the need for experts in all areas and steps of software development.
Everybody involved in software development should be an expert. You wouldn’t hire non-expert QA people to do QA work. There’s no point and no real time or money savings. SAFe’s advice to avoid working with specialists and experts doesn’t make sense on any level. Hopefully they will fix this in later versions.
UX should be on the Agile team and included in all meetings. Early portfolio and planning work must include UX so that others aren’t guessing at what UX will do and how long they need to do it. There are a lot more complexities here, but that’ll be another article. This one is just to show where SAFe and UX can’t converge if you follow SAFe by the book.
