This month, I helped a scrum team to transform their planning and collaboration way, the way of working of different skills together as a team. I want to tell their story here and how we solved one of their tough challenges.

Problem:

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. After several days she could start his task and usually, in the implementation process, she found some problems, and it caused them to went back and forth between tasks. Finally, at the end of the sprint, there was no Done Increment, so sprint reviews were useless, with no feedback loop and …

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 to this challenge.

Solution 1:

“Start backend and design tasks one sprint prior to the frontend task.” It was one of the proposed solutions. Consider, We want to create a login page, so let’s break it down to 3 tasks: 1- Design of login page 2- Implement the API of login 3- Implement frontend of login.

If we postponed 1 of the tasks to the next sprint, so 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, optimize predictability, and control 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 big 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, 3 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 tower and designing a high-fidelity prototype with all details and handover it to developers for implementation. So other team members need to wait for several days to get the designer’s artifacts. It will create a delay and will increase the cost of change. In most cases, they don’t accept changes or feedbacks too, 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 get a clear understanding of the functionalities and designs that 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 on in development.

Low fidelity wireframes are just a quick sketch 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 to let them interact together and break down the silo mindset. Talk together and create a shared understanding. We use the 3 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- Make an agreement on API Contract

It’s time to make an agreement on API contract. Today most modern software is based on API and JSON. The first step is to talk and make an agreement about API contract and so 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 it easy to create a shared API contract.

You can open your favorite editor, and type your JSON. Or you can use the on-the-shelf tools. In the next step, You can use an API mock server to test and call your Mock APIs too.

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 kind of Mock APIs (Mock API for microservices, Mock JSON API, Fake JSON API)

Swarming of 3 amigos is great practice, to create a shared understating between individuals with different skills and create an agreement to make sure everyone can start it without delay. This practice is not just helping people to start their tasks together, 3 amigos swarms together to decrease the feedback loop and reduce the change cost.

Please let me know what do you think about this practice 🙂

Regards

Asad