Of all the myths, this one is the hardest to understand. After all, the idea that we should be getting constant feedback from users is right there in the Manifesto! Isn’t that a pretty strong argument for research? Unfortunately, while some agile teams do a great job getting feedback on work that has already been released, their processes don’t have a natural place for proactive research.
What This Looks Like in the Real World
The most common way that this manifests on teams is with the phrase “Oh, we don’t have time for research” and with designers getting assigned to “create designs” for things in a couple of days with absolutely no research time.
Often this happens because research is still seen as a separate team. Even if there is a cross-functional team with designers, engineers, and product people, research can be an external resource that is only brought in for certain things. Unfortunately, this can be the worst of all possible solutions, since the team gets used to thinking of research as “something done by somebody else,” but they also get out of the habit of waiting for the research to get done before making important product and design questions.
Sometimes teams compensate for this problem by creating something called Sprint Zero, which is just a single sprint dedicated to research and design before the engineers start developing. This just turns into a series of tiny waterfalls, and it frequently fails because not all research and design fits neatly into a single sprint!
How To Fix It
In order to fix this, we really have to embrace the cross-functional nature of agile teams, which means more involvement from everybody in the research and design of features. Instead of seeing research as something done by a different silo, the whole team owns it and runs experiments and studies together in order to inform their decision making.
This can work in a bunch of different ways, and it doesn’t necessarily mean that all engineering work stops while everybody goes to every single user research session! The key things to remember are that research is still incredibly important to making products that truly solve a problem for real people and that understanding our users is not something a team can outsource to somebody else.
© Copyright from IDF (Interaction Design Foundation)
https://www.interaction-design.org/courses/agile-methods-for-ux-design/lessons/2.3
Ruhul's Blog 