Design, backend and frontend collaboration problem in scrum teams?

November 5, 2020Last updated on: November 5, 2020Published by: Asad Safari 4

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

https://mentormate.com/blog/low-fidelity-wireframes-vs-high-fidelity-wireframes/

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.”

https://uxdesign.cc/why-low-fidelity-wireframe-curious-in-product-design-c7bea87bc23d

At this step, we can invite the product owner too. I suggest using a whiteboard(even miro for remote teams) for wireframing.

https://www.slideshare.net/jeffpatton/user-story-mapping-discovery-the-whole-story

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.

https://www.jpattonassociates.com/read-this-first/

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

Agility

You need to stop using buffer to manage unplanned work in Scrum

July 28, 2020Last updated on: July 28, 2020Published by: Asad Safari 0

Dev Team: “Hey Mike (Scrum Master), We have lots of unplanned work during the last sprints, How we should handle them?”

Mike: “You can create a buffer space in your sprint plan”

https://medium.com/agilelab/strategies-for-handling-unplanned-work-during-sprint-2f89697509ff

Dev Team: “It looks great… Let’s do it”

What is buffer space?

Based on this story, During sprint plannings reserve some buffer in a sprint backlog. There are two ways to do this. First, you can plan a virtual backlog item of a certain size that will count towards your velocity. This is going to be your buffer. Each time a new user story or bug enters the sprint, you subtract its size from the buffer item until it reaches zero. From this point, all the new work will be rejected by the team and put to the product backlog. Second, you can simply plan fewer items than the usual sprint velocity. During the sprint, you just absorb new user stories. This difference between average velocity and forecast velocity will act as an implicit buffer.

But why buffer technique is not a good practice in most cases?

Let me tell you a real story. Some time ago, I started coaching an agile team. The team had been adopted Scrum for a while. But the manager was not at all satisfied with the team’s delivery rate per sprint. The team attributed this low delivery rate to the amount of unplanned work on each sprint. To solve this problem, the team used the buffer practice to be able to make better predictions in each sprint. But in practice, there was no significant difference.

When I started to work with this team, my initial goal was to maximize transparency to be able to answer this question, “Why do we have this amount of unplanned work?”

Before taking any action, As a coach, we must have a clear understanding of the situation and, more importantly, make it clear to everyone

What did you get from this visualization?

Let’s look at the above image, I think you got the idea that why we should not use the buffer. This visualization uncovered that there is a high level of technical debt, and in fact, When you adopt buffer technique in this case, instead of solving the root of the problem, you hide it.

An old Japanese saying mentions hiding an offensively smelly object by covering it up.

This amount of bug rate certainly indicates the low level of quality of the Codebase. There is probably no automated tests. The design is very fragile, because, with each sprint as the new feature is developed, the next sprint has more bugs. You can find a pattern.

“Scrum is like your mother-in-law, it points out ALL your faults.” — Ken Schwaber

The basis of the Toyota production system and Lean is the absolute elimination of waste. Don’t Hide the Wastes, Visualize them, and solve the root problem.

When the problem is clearly understood, improvement is possible.

Sometimes (though not always) the buffer hides the root of the problem. In fact, the result will not be satisfactory, and we actually covered the problems.

The next time you encounter unplanned works, first check the 7 wastes of lean software development. Try to make them clear and visualized, and the solution will emerge itself.

While problems observed at the surface level can often be addressed with a simple readjustment, the lean mindset pushes us not to assume that every issue can be solved by simply treating the symptom or adjusting at the surface level.

In my case, After visualizing, we started to create a plan to manage our technical debt, we added a technical mentor to the team, we adopted XP practices…

Best Regards

Asad

Agility

Two ways for better planning and estimating

August 12, 2019Last updated on: August 12, 2019Published by: Asad Safari 2

-“How is it possible to better estimate sprint backlog issues?”

-“Why do you need a better estimation?”

-“You know, In the sprint planning meeting, the team fills the sprint with lots of issues, but in the middle or at the end of the sprint we have to remove lots of them from our sprint’s plan.”

-“With better estimations, Why do you think the same thing won’t happen again?”

All over the world, most software development teams are using Scrum. They have accepted it that software development is a complex thing. So something like waterfall not works in the complex domain, and you need a tool or method or practice to solve this complex problem.

Based on my experience, most of these teams are looking for a magical way to have an accurate plan for their sprints.

In this story, I would like to share my own experience with these teams and share Factful planning framework, a tool that helps you to have

better plannings and estimations.

Problem

The main problem is that we forgot the “Problem.” At the first level, we need to check some understood assumptions. Scrum (n): A framework within which people can address complex adaptive problems.

In theory, everybody has accepted that: First. Scrum is a framework, Second- A framework to address complex problems. However, in real-world, the people act with Scrum as a project management technique. The big problem with this idea is that they forget uncertainty.

In the complex domain, you need to accept uncertainty as a reality, and you can’t ignore it.

Is it possible to plan and estimate in this uncertain world? I suggest you “Factful planning framework.”

Determine the uncertainty level with uncertainty matrix

The first thing is that the uncertainty level of product backlog items is not the same. Any item has a different level. You can determine this level with uncertainty matrix.

Uncertainty matrix is a simple tool to help you to understand your backlog’s items uncertainty level. This matrix has two dimensions.

1- What: What we should do?

2- How: How we should do it?

Grab one of your product backlog items, and look at this issue, first think about “What” dimension. Answer the following question:

Do you(or your team) know what you should do for this issue?

1- Yes, We are sure about detail, and we need to do it

2- Yes, But we are not sure about the details.

3- No, details are unknown

After, “what” dimension, think about “How” aspect. Let’s answer this question:

Do you(or your team) know how to do it?
1- Yes, We are sure about to do it(We have already experience about it)
2- Yes, But we are not sure.
3- No, we need to test different things.

After that, you can choose uncertainty level for your backlog item, for example, 2–3, it means 2 in what dimension and 3 in How aspect.

Factful planning in the scrum events

Let’s think about this example; you have a high priority item with 3–3 uncertainty level. Because this item is a top priority, you select it as one of the current sprint backlog items in the sprint planning meeting, and you ask the team to estimate it.

How should the team estimate this unknown item with a high level of uncertainty? What is the value of estimation when it is wrong?

So, Uncertainty level will help you think about the main idea of Scrum again, “Address the complex problem.”

Factful sprint planning

The first idea is to do not select items with uncertainty level 3(What or How) to implement it in the current sprint. Try to choose items with uncertainty level of 1 or 2.

What about the third level of uncertainty?

Why should we not select them for current sprint? It’s impossible to estimate this kind of items. When you choose them as committed items to current sprint, our stakeholders will think, you need to finish them in this sprint, and this is part of your commitment.

Strategies for the third level of uncertainty

Answer this question: “What can we do in this sprint to create knowledge to decrease the uncertainty level of this item?”

With remembering the uncertainty, the team, instead of being committed to doing unknown issues, they will try to create knowledge and increase the certainty level.

Practices to increase certainty in “What” dimension:

1- Design Sprint

2- Talk with customer

3- Create MVF (Minimum valuable feature)

4- Take time to break down it and write acceptance criteria(like grooming meeting)

5- Functional Spikes

So, you are trying to increase the certainty level in what dimension. I met some teams that they don’t have any communication with their customers.

In some cases, just small talk with a customer can decrease the uncertainty level. Sometimes you need to create a prototype or some methods like design sprint. Sometimes you don’t have time to break down product backlog’s items or write acceptance criteria for them? Maybe you need grooming or refinement meetings.

Spike

Based on Agile Dictionary definition, Spike is a task aimed at answering a question or gathering information, rather than at producing a shippable product.

Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

Functional Spike, This kind of spikes trying to answer a question in the functional aspect. Ex. “Do we need this button here or not?”. A functional spike can be something like that “Prototyping of asset management console.”

Practices to increase certainty in “How” dimension:

1- Technical Spike

Like functional Spike, This is a very simple program to explore potential solutions. For example, “Which library is good for SNMP scanning.”

This kind of spikes will help us to explore solutions and decrease uncertainty.

“What” vs. “How”

If you have an item with uncertainty level 3–3, What is your priority? Based on my experience, you need to start with “What,” Because “How” really depends on the requirement, and we need to determine our technology based on our requirements.

What about change?

Don’t make wrong; we can’t ignore the change. Uncertainty level can be changed over-time based our knowledge about business and technology. This practice is a simple tool to remind you about reality, “Uncertainty.” Instead of taking lots of time for an accurate plan or estimate, work hard to create knowledge at the right time.

Factful sprint review

One of the other practices of Factful planning is “Demo for.” Like the uncertainty level, you need to add a new property to your backlog’s items, “Demo for.” You need to determine at the end or during the sprint, Who should see the result of this item? Who should provide feedback to us?

In some cases and in real-world, items with uncertainty level 1–1, don’t need any specific feedback from the customer, and this can be accepted or rejected it by our product owner. But other items with higher uncertainty level needs real customer feedback.

You can not write a general thing as a demo for, like “somebody from marketing.” If you are building a feature for the internal inventory system, you need to write something like that “John, head of inventory and Sara inventory software user.”

Why “Demo for” practices?

1- sometimes, we have different items for different segments. With this practice, we know that we should get feedback from the right person.

2- Don’t waste your time to get feedback for some 1–1 item. (They will make our review meeting so dull)

3- You can send an invitation letter to them, to join you and make themselves available for you. They have time for preparation and set the meeting on their calendar.

4- You will not forget to get feedback.

Why do I call these practices Factful planning?

We need to learn to separate fact from fiction when forming our opinions. The organization can be both bad and better. Progress comes bit by bit, But without facts, our minds are occupied by feelings. This practice is part of my factful agility toolbox.

Asad Safari

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He has worked as an Agile coach for more than 7 years with several enterprises and startups. He has more than 14 years experience in the IT industry as a Software Developer, Tester, and finally an agile practitioner. You can follow Asad on Twitter and LinkedIn.