A SCRUM Approach for Multi-organisational Teams - UX Case Study of OBID

Scrum methodology illustration

During my last year at VW, I had the privilege of being an integral part of a highly efficient and cohesive Scrum team. Our collaborative efforts were focused on a pivotal SaaS project known as "One Business ID," the details of which are available in the portfolio linked HERE. The experience of functioning within such a well-orchestrated Scrum team consisting of four different organisations, led to the following insights and reflections.

What is SCRUM?

In essence, Scrum is an agile framework tailored to foster collaboration and break tasks into manageable chunks called sprints. It facilitates adaptability and iterative progress. Especially beneficial when coordinating among multiple organisations like it was in our case.

Team Structure in Our SCRUM Project

  • UX/Product Team: Comprising two UX designers, including myself.
  • Project Owner: Responsible for maximising the value of the product.
  • Scrum Master: Facilitates the SCRUM process and removes any impediments.
  • Developers: Responsible for coding and building and UX designer best friends.
  • Q&A: Ensuring that the final product meets the necessary quality standards.

Meeting Rhythms and Patterns

Our Meeting Schedule:

  • Daily SCRUM: A short daily meeting where we discussed progress and challenges.
  • Sprint Review: At the end of every sprint to demonstrate and review what was accomplished.
  • Retrospective: Post-sprint meeting to discuss what went well and areas of improvement.
  • UX/Product meeting: Discussing new feature designs and ideas with the PO and developers.
  • UX internal: A synchronisation touchpoint for the UX team.

Sprints: It Actually Works

Working in Sprints:
Sprints are pre-defined periods where specific tasks are set and completed.

Differences for UX and Developers:
The UX/Product team consistently operates one sprint ahead of the developers – a practice that might align with textbook SCRUM methodologies. However, in our unique scenario, the product team worked a full Product Increment (PI) ahead. This strategic approach afforded us ample time for design construction and testing. Moreover, it allowed us to seek input from developers at an early stage, resulting in smoother transitions when we passed on the designs. In most cases, this proactive approach minimised the need for design changes once handed over to developers.

Program Increment (PI) Planning

Our favourite SCRUM component. Despite being a remote team spread across Germany and Portugal, this was the only time we all gathered. The week was divided into four days, and everyone eagerly awaited the evening get-togethers. Here's a quick peek into our PI planning.

The key elements of a Program Increment include:

  1. Time Frame: A Program Increment typically spans 8 to 12 weeks, although the duration can vary based on the organisation's needs and the nature of the project.
  2. Planning: At the start of each Program Increment, teams engage in PI Planning, where they collaboratively plan and align their work for the upcoming increment. This involves defining objectives, identifying dependencies, and outlining the features or stories that will be developed.
  3. Execution: Throughout the PI, Agile teams work on their respective features, stories, or tasks, aiming to achieve the objectives set during PI Planning.
  4. Synchronisation: Regular synchronisation points, such as Scrum of Scrums meetings, help teams identify and address cross-team dependencies, bottlenecks, and challenges.
  5. System Demo: At the end of the Program Increment, teams come together for a System Demo, showcasing the integrated and potentially shippable product increment to stakeholders, customers, and other teams.
  6. Inspect and Adapt: There is a text book way to do this but as a UX/Product team we had our own method. Here we documented everything that needs to be done by us for the next PI planning and we discussed this together with the product owner to be on the same boat.

Different UI assets in a isometric view

Communication is King

SCRUM isn't a magical solution for flawless project execution. If team members lack alignment or communication breaks down, issues arise. A clear instance of this unfolded when I joined the project. Despite the previous UX designer's three months of work, underlying dissatisfaction led to his departure due to communication and respect issues. This experience highlighted that developers rely on us for timely answers. Delays of weeks disrupt their progress, causing frustration and rework. I committed to resolving this by initiating 1:1 calls with developers, fostering trust and responsiveness. This approach continued with quarterly sessions to address any concerns. In SCRUM, strong relationships are vital for success.


Proactive UX Design

The UX Design Process:
Proactively, we didn't wait for instructions; we actively sought ways to enhance the designs. While suggesting improvements, we were mindful of developers' workload, preventing overload. During less intense periods, we revisited previous features, offering recommendations. These ideas entered the backlog, waiting for implementation when the team's capacity allowed.

The Backlog: An Ever-evolving To-do List

The backlog is a prioritised list of features, bug fixes, and other tasks to be tackled. It's continuously updated based on product needs, customer feedback, and team input.

The Significance of Documentation

Why Documentation Matters:
Documenting, my friends, can truly be a game-changer. It saves you from hours of guesswork and prevents unnecessary arguments. Our approach to documenting meetings and decisions went beyond mere formality. It became a treasure trove for upcoming designers and team members. Whenever doubts surfaced or the need to track back arose, our documented records came to the rescue. We utilised Confluence's Kanban board for documentation, linking the right tickets and providing an accessible overview for all. Yet, the choice of a Kanban board can depend on your team's preference.

Product Improvement

Let's delve into an illustrative example of how we enhanced our product. Our improvement journey followed a consistent path: we would develop a feature, subject it to testing, and subsequently incorporate feedback for refinement. In the subsequent Product Increment (PI), we'd address the identified issues. While we were fortunate to encounter relatively few of these instances, one notable example revolved around customer deletion.

The deletion of the customer:

At the onset of the year, we crafted the initial screen. Following its publication and subsequent test analysis in the second PI, an update to the deletion process became necessary. As depicted, the initial flow consisted of two steps, each accompanied by separate pop-ups. This configuration posed a potential vulnerability wherein account deletion could be achieved with swift consecutive clicks.

The Solution.

  1. We streamlined the process by introducing a single pop-up.
  2. We incorporated a deliberate, sequential click requirement for account deletion.
  3. Our solution involved incorporating explicit text and a checkbox. The solution entailed activating the checkbox; until this action is taken, the pop-up's continue button remains inactive.
UI screens of a fixed UX flow

Conclusion

Firstly, effective communication within the team is paramount; without it, roadblocks emerge, and dissatisfaction ensues. Designers must adopt a proactive stance, questioning design decisions to enhance the product. Documentation proves indispensable for the design team, sparing hours in the long run and curbing confusion for new team members.

Moreover, I discovered that SCRUM isn't an inflexible blueprint; while some adaptations are necessary to suit specific needs, it serves as a solid foundation. SCRUM is an exceptionally well-suited approach for collaborative work in a multi-organizational product team.