Adapting Scrum to a UX Model
Published: July 7, 2014
Agile methodology—more specifically Scrum—is an increasingly popular approach to increasing the speed of software development while maintaining flexibility. Scrum works well when an entire team is collocated. Real-time communication happens between team members during daily Scrum meetings. But assume part of a team is operating in a different role, from a different location. Sound challenging? In this article, I’ll try to answer some common questions about user experience and Scrum by exploring the challenges a Development team faced when working with a separate UX team on a Scrum project. I’ll also provide recommendations for UX teams that are part of a Scrum team.
While the information in this article reflects my experience working with my clients, confidentiality prevents my discussing specific situations, so I’ll instead present a scenario that is based on some challenging situations that I’ve actually encountered in my work. This scenario resembles real situations from a very successful project on which the UX team was not colocated with the rest of the Scrum team. I hope this article will be useful to both UX professionals and software developers working on Scrum projects.
In this scenario, there are two teams working together on a Scrum project from two different locations: a Development team and a UX team. According to the agreed-upon plan, the Development team is dependent on the UX team for wireframes, design comps, and graphic design assets, without which they cannot start development. To make things a bit more challenging, let’s assume that the UX team is a third-party vendor that does not usually follow the Scrum methodology as part of its day-to-day delivery model. However, they must for this engagement.
Following the Basics of Scrum
Adhering to Scrum principles and practices is what it makes a Scrum team effective in action. For example, a team must follow Scrum roles and processes by the book. Each Scrum team comprises a Product Owner, Scrum Master, Scrum team members, and a Business System Analyst, who may act as a substitute Product Owner and works with the Scrum team on a regular basis. The team participates in scheduled sprint meetings and works toward the common goals of designing, coding, and testing a deliverable—whether a new feature or just a bug fix. During each sprint meeting, the team goes through the product backlog, sprint backlog, and burn-down charts.
In this situation, a separate UX team that did not follow Scrum as a part of its delivery model would present serious challenges to the team’s realizing the benefits of Scrum. For example, a project might experience deliverables churn, get delayed because of misaligned schedules, get blocked by a slow approval process, or experience communication breakdowns.
Tips for Working Successfully on Scrum Teams
So, how can UX professionals succeed in such a situation? What are the key adjustments that it’s necessary for a team to make to the Scrum methodology to enable them to succeed when working with a separate or an external UX team? Here are some recommendations for mitigating the challenges and risks that are associated with separate UX and Development teams working together.
- Plan in a fluid manner and onboard the UX team to Scrum. The entire Scrum team—incorporating both the Development team and the UX team—needs to follow identical principles, speak the same language, and use the same terminology. Provide a basic overview of Scrum to all UX team members at the beginning of a project.
- Schedule the UX team deliverables such as wireframes and visual design assets at least two sprints in advance to align the UX team’s timeline with the Development team’s sprint schedule. This change will allow the Product Owner sufficient time to carefully review the UX team’s deliverables and catch issues such as system limitations and areas of unwanted customization. Complete the technical review in advance or during the first sprint.
- Involve a developer in the review of UX deliverables. Product Owners are not developers. So the chances are high that they may have difficulty understanding technical capabilities. I recommend involving a developer in the review cycle to help reduce the likelihood that significant design changes would be necessary during the sprint, which could jeopardize your target dates and reduce development speed.
- Use the second sprint to revise design deliverables and get stakeholder approvals. During the second sprint, the UX team should get time to make any necessary updates to the wireframes and visual design assets based on the feedback that they’ve received from the Product Owner and developer. But what about the stakeholders’ approval? Use this sprint window to get stakeholder approvals. By allocating time for signoff, the Product Owner ensures full business buy-in for all UX designs that the Development team implements. The sprint plan should expect and allow business stakeholders to request tweaks to UX designs when they later see demos, but this early review and signoff prevents the need for a complete revamp or large changes to the project during development.
- Allow time for planning. The UX team is more effective when it has time to plan and assign the most appropriate designers to each project. So make sure that the UX team lead or manager has an opportunity to voice concerns early and has complete visibility into the upcoming work. Be sure to provide a clear view of the project pipeline, agree on UX delivery dates, and provide guidance to the UX team, not detailed Business Requirement Documents (BRDs). You need to give the UX team room to be creative. The Product Owner should work closely with the UX team lead or manager to convey the vision for the project and may help by sharing examples that relate to a few complex modules and referring the team to Web sites or applications with similar functionality.
- Facilitate communication between the UX team and the Development team. Remember, the UX team and the Development team are not sitting together. So formal feedback makes communicating the need for any minor rework or superficial changes easier. Ask the Product Owner to expand his role and take on responsibility for facilitating communication between the UX team and the Development team. Choose a Product Owner who has strong communication skills; who understands wireframes, visual design, and technical development; and who has the ability to answer questions that come from the UX team. The Product Owner should act as a bridge between the UX team and the Development team.
- Use collaboration tools to facilitate the Scrum team’s work. The Product Owner should leverage the use of various tools to make teamwork easier. Agile tools are fantastic for helping Development teams organize sprints, maintain the product backlog, and report progress. The Product Owner must encourage the team to use spreadsheet-based feedback forms, agile tools like Jira, and file-sharing networks. Using a file-sharing tool is essential. There can be a huge number of UX artifacts such as wireframes and visual design assets. Exchanging them as email attachments clogs people’s inboxes and creates confusion—particularly as the number of versions increases. When files get buried in people’s inboxes, it’s difficult to find them. Tools like Dropbox, Google Drive, Google Docs, and OneDrive solve the problem of email systems’ file-size limitations, too. The Product Owner must make use of solutions like Confluence or SharePoint to maintain strict version control and provide an archiving mechanism. The file-sharing system must be open to the entire team, enabling both UX and Development team members to upload and download the files. When a team member uploads a new version of a file, the older version of the file must be moved to an archive folder.
- Communicate face to face whenever possible. Direct, face-to-face communication is always helpful, provides greater insights into UX design, and reduces the likelihood of miscommunications and gaps in requirements. However, if face-to-face communication is not possible, the Product Owner should liaise with a UX Project Manager. Conference calls and collaboration systems like WebEx provide alternatives that teams can use. The Product Owner must keep the UX team lead or manager in the loop regarding any change requests, so he or she can manage the workload across the UX team. When working with a UX team lead or manager, the Product Owner should plan extra time for design updates and pad the ultimate delivery date to allow for inevitable mid-sprint change requests.
- Include the UX team in feature demos and reviews. When allocating development time based on the development of specific features, the Development team has limited time for making corrections or adjustments before they must move on to the next feature. Invite the UX team to demos so they can hear stakeholder feedback directly and can immediately identify small implementation errors that developers can quickly fix. By including the UX team in reviews, you ensure that everyone can quickly achieve alignment on any necessary adjustments.
On a Scrum project, a UX team that does not follow Scrum as part of its delivery model presents a serious challenge to realizing the benefits of Scrum. To solve this problem, someone from the Development team must serve as a point of contact and work closely with the UX team on a regular basis to align the two teams’ timelines, as well as their expectations in terms of deliverables and requirements. This will ensure the timely delivery of UX design artifacts, better alignment on requirements, and a consistent process for providing feedback to the UX team before development starts.