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
