How to create real self-organized teams

Last updated on: Published by: Asad Safari 1

In my last 10 years’ experiences, one of the buzzwords in the agile community was the self-organized teams. everyone talks about it but no one knows how to create one.

It’s all about decision making

All teams face two types of issues, decision making, and execution. When a team is not self-organized, somebody(that we call it manager) makes all decisions and the team just executes them. Whenever we want to create a self-organized team, we should delegate part of or all of these decisions to the team.

Delegation

It’s all about delegating

Management and leadership books talk about delegating authority. But if you have the experience of managing even a small team, you know how difficult it is. Delegation of any kind of decision depends on two important factors:

  1. The level of maturity
  2. The impacts of the decision

If you have an immature team, give them a lot of authority, the team may get into a chaotic situation and even do the opposite. In contrast, if you have an experienced team, and you do not give them any authority, it will be very tedious for them just to do tasks.

How To balance the authority and team maturity

I have used the management 3.0 delegation poker game to balance the authority and team maturity.

There are plenty of “shades of gray” between being a dictator and being an anarchist. Most managers think they should act like a dictator or anarchists. The etymological origin of anarchism is from the Ancient Greek anarkhia, meaning “without a ruler”, composed of the prefix an- (i.e. “without”) and the word arkhos (i.e. “leader” or “ruler”). (Wikipedia)

Delegation is a step-by-step process. You hand over accountability to other people in a controlled and gradual way. In addition, it is context-dependent. You want to delegate as much as possible but if you go too far chaos might unfold.

How to delegate in action

Delegation is not a binary thing, based on this model, there are 7 levels of delegation-level:

  1. Tell: As a manager, I make decisions and I will tell them.
  2. Sell: As a manager, I make decisions and I will try to sell them.
  3. Consult:  I will consult and then decide.
  4. Agree: We will decide together.
  5. Advice: I will advise but they decide.
  6. Inquire: I will inquire after they decide
  7. Delegate: I will fully delegate

Visulize current state of delegtation

The second rule of delegation is: “Delegation is a step-by-step process. You hand over accountability to other people in a controlled and gradual way. In addition, it is context-dependent. You want to delegate as much as possible but if you go too far chaos might unfold. “

The first stage of creating a self-organized team is to visualize the current state of delegation. check the following image:

1- For two or three weeks try to log your decision, for example, “Today I have hired a new team member”, “Today, I asked the team to implement a new feature”…

2- Create a delegation board in miro or mural, and visualize the current state

3- Let the team understand the current state and explain the model to them

4- Let them decide about the future state and you as the manager tells them about the impacts.

5- Review this board at the retrospective meeting and make a decision about the future state again. Delegation is a step-by-step process. You hand over accountability to other people in a controlled and gradual way.

The main idea is to delegate authority to the team as much as you can, but this delegation will be based on the context and maturity of the team. Visualizing this process will increase transparency, which can increase the level of maturity of the team.

Let what do you think about this process?

Regarads

Asad

Design, backend and frontend collaboration problem in scrum teams?

Last updated on: Published by: Asad Safari 2

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.

Late feedback = High cost of 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?

Swarming of 3 Amigos

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)

https://mocki.io

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