Design, backend, and frontend collaboration problems in scrum teams?
This month, I helped a scrum team to transform their planning and collaboration way, the way of working with different skills together as a team. I want to tell their story here and how we solved one of their tough challenges.
Waiting and delay problem. The frontend developer had to wait for several days to get an API from the backend developer and a High-fidelity prototype from the designer(e.g. Figma Design). After several days she could start her task, and usually, in the implementation process, she founds some problems, which will cause them to start a back and forth between BE and FE and Designer. Finally, at the end of the sprint, there was no Done Increment.
So, How a cross-functional team should work together to create a done increment in just a two weeks time-box?
Facilitate sprint retrospective to find the solution
At the sprint retrospective meeting, the team raised this issue as the main problem, and we tried to find solutions.
“Start backend and design tasks one sprint prior to the frontend tasks.” It was one of the proposed solutions. Consider, We want to create a login page, so let’s break it down into three tasks: 1- Design of login page 2- Implement the API of login 3- Implement the frontend of login.
If we postpone 1 of the tasks to the next sprint, then we will not have a Done Increment at the end of the sprint.
Based on the Scrum Guide:
“ Scrum employs an iterative, incremental approach to optimize predictability and to control risk. “
This solution terminates the main purpose of the scrum, optimizes predictability, and controls risk. Late review= Late feedback loop. This approach will increase the risk and the cost of the change.
Sarah: “We don’t have any other alternative….”
In addition, this kind of solution shows a significant underlying problem, Waterfall and Silo mindset in Agile’s clothing. When team members don’t care about the working software and early feedback, you should find a way to help them be agile and not just do agile.
“If you want to teach people a new way of thinking, don’t bother trying to teach them. Instead, give them a tool, the use of which will lead to new ways of thinking.” Buckminster Fuller
Solution 2: Swarming of 3 Amigos
Swarming of 3 amigos was the practice we experimented it in the next sprints. Before starting any product backlog item, three amigos need to swarm together. Swarm to do what?
1- Start with low-fidelity wireframes instead of high-fidelity wireframes or prototypes
Most designers used to sit at their ivory towers and design a high-fidelity prototype with all details and handover it over to developers for implementation. So other team members must wait several days to get the designer’s artefacts. It will create a delay and will increase the cost of change. In most cases, they don’t accept changes or feedback because they have fallen in love with their design.
Based on this article, “A wireframe is the first visual representation of a designer’s idea. It ensures that the developers and customers clearly understand the functionalities and designs the software needs to support. Don’t be fooled. Despite their minimalism, designers can find low-fidelity wireframes inspiring. They are flexible tools that provide room for experimentation. When team members can visualize and agree upon the inclusion of features earlier in the development lifecycle, they spare their clients additional costs later in development.
Low-fidelity wireframes are just quick sketches that can make ideas more tangible. Lоw fidelity wireframes are usually black, and white schemes or simple sketches on paper or whiteboard focused on the “big picture” of the feature or page. UI elements are shown as boxes and lines without detailed annotations.”
At this step, we can invite the product owner too. I suggest using a whiteboard(even miro for remote teams) for wireframing.
Remember that one of the agile values is “Individuals and interactions” this swarming is not just about creating a wireframe; it’s about letting them interact together and break down the silo mindset. Talk together and create a shared understanding. We use the three amigos practice to facilitate a conversation. Shared understanding is more important than shared documents.
The designer can start to design a high-fidelity wireframe after swarming, and other guys don’t need to wait for him.
2- Agree on API Contract
It’s time to agree on an API contract. Today most modern software is based on API and JSON. The first step is to talk and make an agreement about the API contract and create a mock API based on the agreement. The frontend developer can start to implement the frontend of the login page without waiting to finish of backend task.
Acceptance criteria of the user story and wireframe will make creating a shared API contract easy.
You can open your favourite editor and type your JSON. Or you can use the on-the-shelf tools. In the next step, You can also use an API mock server to test and call your Mock APIs.
MockAPI.io is one of the great tools that you use it easily create a mock API.
Or Mock.io is another great tool that you can create a different kinds of Mock APIs (Mock API for microservices, Mock JSON API, Fake JSON API)
Swarming three amigos is a great practice for creating a shared understanding between individuals with different skills and creating an agreement to make sure everyone can start it without delay. This practice is not just helping people to start their tasks together; three amigos swarms together to decrease the feedback loop and reduce the change cost.
Please let me know what you think about this practice 🙂
Originally published at http://factfulagility.com on November 5, 2020.