A couple thoughts.
There are no prescribed processes/practices/methods in Agile. I think you allude to this a couple times, but it is worth remembering. Teams are free to try new ways of working, reflect, and adapt. Lots of teams evolve quickly beyond scrum.
One of my big breakthroughs in the past year was discovering the simplicity of Modern Agile (Joshua Kerievsky). The four principles are broadly applicable, and not just for developers:
- Make people awesome
- Make safety a prerequisite
- Experiment and learn rapidly
- Deliver value continuously I’ve found these values to be more approachable for non-engineers.
Next, there are many pitfalls to dual-track scrum. On a system level it can discourage iteration/refinement and has the potential to make your UX team’s head explode. Why? There’s another input into the system based on feedback from shipped features, and that makes things very complicated. It’s fine for “landing” designs on a team, but not great for responding to customer feedback. Before you know it the UX team is trying to design, refine, build, monitor, and tweak everything at once. That isn’t safe.
I think you’re on the right track with using Kanban to make your current way of working visual, and using that as a centerpiece for continuous improvement. When you apply this approach to dual-track scrum, I often see some anti-patterns emerge. There’s an effort to “get designs ready for engineering”. That feels very efficient and intuitive. What you often find, however — once you visualize the rework, tweaking, clarification, etc. — is that you would be better off designing alongside engineers. Even if fewer hands are on keyboards.
In my opinion, dual-track scrum is a bandaid which is predicated on the idea that the conveyor belt only runs one way and that idle engineer hands are fundamentally bad. It’s a response to trying to keep people busy. It’s a way to “carve out” UX’s role structurally, when the most evolved teams are able to respect that value without undue handoffs.
Some of the most rewarding, effective “design” I have facilitated has included:
- Design studios with engineers and designers … taking days away from keyboards to wrap our heads around the problem and establish a vision
- Getting everyone on the phone with customers together
- Doing research together. Visiting customers together
- UX pairing with engineering
- Monitoring customer feedback together instead of in silos
- Including usability and users being able to achieve their desired outcomes as a definition of done / acceptance criteria I think that is what you’re getting at by mentioning mobbing? One thing I know for sure … this builds amazing empathy for designers and customers. It is hard(er) on some levels, but a little more sane.
The underlying problem is not an agile problem. It is the idea that our teams are primarily feature factories and that at any moment a product manager is going to swoop in and say “we’ve shipped it, let’s move on”. Both engineers and UX struggle with this, and it forces them to find a lot of ways to ply their craft before someone arbitrarily tells them to ship crappy product… hence craftsperson movements and Sprint 0. THAT is the problem, and that is a business problem. In this regard, UX and Developers actually have a ton in common.
When you commit to addressing that problem, and to experiment/learn and deliver validated value, it makes the discussion of dual-track pretty moot. The team adapts to what’s right for that effort, with a keen eye on delivering great designs and product to customers. Sometimes it will make sense to send designers off on a mission. Oftentimes it wont. Sometimes it will make a sense for everyone to design together for a couple days, and then divide and conquer on some tasks. Instead of UX trying always trying to land a big jet on this fast moving submarine coming up for air … the team takes the optimal course.
Oh geez. I’m blabbing here. Hopefully this makes some sense. Some relevant posts: