UX working a Sprint ahead is full of FAIL. Work as a single team instead.

It usually happens this way. Adoption of agile methods begins with developers. This is because, according to the Agile Manifesto, agile work values “working software over comprehensive documentation”. The rest of project teams are then asked to work around the development effort. In this model, popularised by Lynn Miller and  Desiree Sy in 2007, Jeff Patton notes that user experience (UX) people working on Agile teams become “masters of development time travel nimbly moving back and forth through past, present, and future development work”.

This way of working has a number of benefits for those adopting agile methods like Scrum:

  • Change management: It’s not greatly different to how the team currently works. UX people do design and then “throw it over the wall” to the developers who then implement it.
  • Autonomy: Developers enjoy the autonomy and self-management that Scrum brings them.
  • Time saving: Where previous projects would take many months before tangible products are seen, management, stakeholders and users can see something in a few months.

Problems with UX work being done a Sprint ahead

Working a Sprint ahead, though, has significant problems:

  • Sprints become out of sync: What is simple to design can often be complex to develop, and vice versa. Designing a Sprint ahead doesn’t ensure that the UX team can stay a Sprint ahead. It’s very easy in this method for Sprints to get out of sync.
  • Iteration without agility: Engaging users, and then designing a Sprint ahead, then coding, then testing usability, and then deploying, is essentially a mini-Waterfall approach. It means users have to wait for 5 Sprints before they see anything. If there are defects that have to be addressed then it takes even longer.
  • Lack of ownership of the UX amongst developers: Where UX work occurs a Sprint ahead an “over the wall” mentality evolves. Because developers are not involved in engaging users directly in design they lack the implicit knowledge of users needs gained by the UX people. A lack of knowledge often results in a misalignment between what user need and value and what developers feel is important to deliver.
  • Groupthink: A homogeneous skill set amongst separate UX and dev teams results in opposing opinions about value. This leads to the type of conflict between the teams and individuals known as groupthink.
  • Waste: In Waterfall projects, up to 50% of what is designed is not developed, and up to 50% of what is developed is never used. Where working a Sprint ahead results lack of ownership and groupthink in similar levels of waste occur because (through “over the wall” behaviours and groupthink) developers can feel they are under no obligation to code what has been designed.

Like Luke Walter, of CollabNet, though, I’m baffled as to why people feel these processes represent an agile best practice. It is even more incredulous that these recommendations — that UX work (e.g. user-research, UX design, UI wireframing, etc) should be developed in sprints prior to development, or even generated in backlog refinement/sprint planning meetings outside of sprints — are often recommended by seasoned Scrum practitioners. Luke notes:

“While these folks no doubt would argue that system architecture (high-level software design) can and should be done incrementally and iteratively in regular sprints along with the rest of the development work, they express the opposite opinion on UI design without any sense of irony. “

Is this an issue with agile maturity?

When the processes and attitudes of working a Sprint ahead are viewed in light of agile maturity, however, there is increasing anecdotal evidence coming out of conferences like those run by the Agile Alliance in the USA, that more mature Scrum teams feel it is more valuable for the whole team, developers and UX people, to work collaboratively on a piece of work. This means the whole team exploring design issues, doing wireframes and prototypes together, as well as engaging users to discover requirements and assessing usability, rather than only part of the team working almost exclusively on this effort a Sprint ahead. It is certainly my experience that when a good agile coach has had experience with UX work that this way of working is the one that is recommended.

Benefits with a single scrum team approach

After many failed projects where working a sprint ahead was seen as the process to adopt, I only use a single scrum team approach. As a result after 5 years has been a significant improvement in my project’s risk profiles and the following benefits to clients and stakeholders.  The benefits of a single scrum team approach has been:

  • Improved vision and knowledge of users’ needs: the whole team are involved in progressively understanding what users value and creating the solution.
  • Improved time to delivery: Features can be designed, developed, tested and deployed in a single sprint.
  • Less re-work: As usability is assessed in the same Sprint, it can also be corrected earlier if problems arise.
  • Improved team cohesiveness: Because the team collaborates on all aspects of the solution the whole team owns the end products, not just the developers.
  • Improved Definition of Done: Design – like architecture and testing – is simply work that needs to be done to construct a potentially shippable increment of Product. And most of this work can happen during a sprint with everything else. Where products are estimated as complex, design and analysis work as part of Backlog Refinement helps to improve the clarity of the Definition of Done for upcoming Products.
  • Less waste: Only what is designed in the current sprint is developed, and this means less waste.
  • Transcendence: With multiple view points and perspectives, a diverse and multidisciplinary team are able to approach complex issues from different angles. This challenges the team to come up with smarter, more effective ways of implementing solutions.

Conclusions

While Scrum is agnostic about how the Product Backlog is formed, it is rather prescriptive about using a single, diverse team. This requirement goes all the way back to the original Scrum concept posited in the New New Product Development Game. It’s often easier, though, to stick with what you know and only adopt Scrum in a very minor way with the assumption that it’s only about software development. But there is a fatal irony that comes from this way of working that runs counter to the basis of Scrum itself. For me, the benefits of having a single Scrum team far outweigh the costs. The trick is, though, to have a coach who understands both design and development to help you achieve that outcome.

M

Advertisements

4 Comments

  1. Scott Duncan says:

    What if you happen to have 110+ teams world-wide and you don’t happen to have 110+ UX designers who can work in real-time with each team? I certainly know what you’re getting at with your post and we’d love to do that, but just don’t have the people to do so. Same goes for those who write the customer documentation.

    1. magia3e says:

      Putting reductio ad absurdum aside, there are many case studies that span the last decade of Scrum adoption that demonstrate how Scrum scales to these sorts of levels and how it handles issues regarding resourcing.

      In my own experience, where resources like UX are scarce, and we’ve used the Scrum of Scrums technique, the projects have done the following:

      1. The UX person becomes the Master Product Owner

      2. One UX person works across a number of Scrum teams to assist in what they’re working on within the Sprint.

      3. The UX person creates standards by which other teams follow as a contribution to the Definition of Done and quality criteria.

      Each of these has its own advantages and disadvantages, however, in none of these methods is the UX person required to work a Sprint ahead or behind.

      M

      1. Scott Duncan says:

        For us, the POs need to be rather expert in the domain of our customers which is highly enginneering focused, so people with UX expertise wouldn’t work as POs if we were to expect them to interact with our engineering customers.

        But we do both 2 & 3. In the case of 3, the standards would seem to me to have to be done ahead of expecting developers to make use of them, in fact, probably more than just a single Sprint ahead.

        For 2, some POs view the UX/UI design to be things they want reviewed by customers before developoment occurs. We also have numerous customers in time zones where all of them on a single Sprint Review at a single time doesn’t work. Some of them don’t speak English and need Sprint Review recordings done, then translated for them. In these cases, getting client feedback on design and workflow ahead of committing to development is important.

        I know this may not be the typical profile for teams working in an Agile/Scrum environment, but we’re trying not to fall into (too much) waterfall behavior given the nature of the global customer base. UX/UI considerations, for us, fall somewhat between design and requirements so it seems hard to do them completely iteratively within Sprints.

      2. magia3e says:

        It sounds like a very interesting environment in which you’re applying Scrum. I suspect, though, that there are a number of improvements that could be made, even looking at Scrum of Scrums processes, to make Scrum work even better for you.

Comments are closed.