The Agile Wilderness: Principle #11: Self-Organizing Teams

The Agile Wilderness: Principle #11: Self-Organizing Teams

Agile Principle #11: "The best architectures, requirements, and designs emerge from self-organizing teams." (1)

No alt text provided for this image

Image from medium.com (2)

When I first think of the term self-organization, I think of people who select which team they want to be on. This concept came about from talks I have heard from folks such as Heidi Helfand who wrote dynamic re-teaming. (3) The diagram below shows the cycle focused making sure our teams don't fall into a rigidity trap and have creative destruction from dynamic reteaming. This cycle helps teams to stay fresh and passionate about what they are tackling. This is however not what most people think when they hear self-organizing teams as you will see below.

No alt text provided for this image

Digging into the agile principle

As we investigate this principle, it calls out 3 areas that improve when we self-organize but let's first talk about what self-organized means. At the core of self-organization is a team focused on improving on their own. This goes back to a culture of trust and empowerment from leadership and the team taking on that ownership.

According to scrum.org "Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team." (4) As you read through the rest of the article, you will see there is a focus on empowering the team to make their own choices such as with estimation or the way they do their work. Another key item discussed as part of a self-organizing team according to plan view "...is?one that does not depend on or wait for a manager to assign work. Instead, these teams find their own work and manage the associated responsibilities and timelines" (5)

No alt text provided for this image

So, what happens when we give folks the ability to organize themselves. According to this principle, 3 keys things happen which are that we get better architectures, requirements, and design. Why might you ask? It is not directly stated in the principle however if you have people who are trusted and empowered to own their work and do it the way they want to, the more likely they are to really care and put more effort and focus on their work leading to better things.

Comparing the agile principle to Scrum values and SAFe scaled principles

Scrum values of commitment and respect all apply as we think about self-organization. (6) As a team we need to commit to one another to achieve the goals we have as a team and respect what each of use bring to the table. We talk through as a team how we want to work together to accomplish these goals.

No alt text provided for this image

As we look at the scaled principles from SAFe, we see the concept of decentralized decision making expand from this principle. (7) In decentralized decision making, we want our teams to be empowered to make any decisions they are in the best position to be able to make and are not going to have organization wide effects. See chart below for SAFe formula to determine where the decision should be made.

No alt text provided for this image

Suggested changes to the original agile principle

This principle uses outdated and confusing language. I also do not understand why only architecture, requirements, and design are helped by self-organizing teams and not value delivery. If you think about what this principle was trying to achieve, I would reword it to say "The best product solutions and outcomes emerge from teams who choose how they work together". This moves our focus back to what is important as a team using more updated language and explains what self-organization is rather than use a term many do not really understand.

Closing

In closing, a team who is empowered to choose how they work together will drive better results and be a happier team. Below is a summary of the content from the article:

No alt text provided for this image

I hope you have enjoyed this article and as always feel free to reach out to discuss further or drop a comment below to join the discussion. Thank you for your time and look forward to sharing my thoughts about "Principle #2: Changing Requirements" next time.

About the Author

Follow #theAgileMoose for the latest insights in the agile wilderness

No alt text provided for this image

Jeff Mortimer?(#theAgileMoose ) is an Agile Enthusiast with over 10+ years of experience working in various roles on agile teams including business analyst, product owner, scrum master, team leader, technical delivery manager and now an agile coach consultant focused on product transformations. In additional to his certifications in CBAP, AAC, CSP-PO, SAFe Agilist and SAFe LPM, Jeff?has presented at several conferences throughout North America and joined the blogger universe a couple years ago to bring a voice to the everyday agile practitioners. He also just received his EMBA at Quantics School of Business and Technology. He is a husband to an amazing intelligent wife who has her doctorate in math education, father to kids who bring him joy every day, friend that brews beer and plays soccer, and citizen who helps organize volunteers to give back to the community.

References

(1)?Agile Principles ?from agile alliance

(2)?Principles Image ?from medium.com

(3) Dynamic Reteaming by Heidi Helfand

(4) Self-Organizing Teams from Scrum.org

(5) Self-Organizing Teams from Planview

(6)?Scrum Values ?from scrum.org

(7)?SAFe Scaled Principles ?from scaledagileframework.com

要查看或添加评论,请登录

社区洞察

其他会员也浏览了