About selforganizing teams Clementino Mendonca March 3 2016

About self-organizing teams Clementino Mendonca, March 3, 2016 CSc 233 Fall 2019 BB

Question from a budding Scrum Master “In order to promote team bonding and selforganization, from now on I am going to try something new with the team. In the sprint planning meeting, instead of me breaking down the tasks for user stories between each team member, I am going to just identify tasks and hours needed and leave it at that, and then I will ask each team member to “pick” tasks from the sprint backlog on their own, and later, as soon as they complete a previously picked task. ”

The behavior I want to encourage is the following • Each team member will see their list of pending tasks as dynamic, depending what is remaining for the team and not just for the individual as assigned in the beginning of the sprint • Before team members can pick new tasks to work on, they will need to self-organize, that is, communicate and coordinate with the other team members instead of just focusing on their own part of the effort. • Has anyone tried something like this before? Essentially this is a 'pull' system instead of 'push' system where the instead of someone assigning tasks to team member, the team member decides which tasks they want to work on.

My answer, in my experience as a Professional Scrum Master, and Professional Scrum Trainer was the following “Your recommendation is definitely a best practice for Scrum Masters. In organizations still transitioning to Agile in many cases work is distributed exactly as described, by "breaking down the tasks for user stories between each team member" (that is, "assigning" work). Notice that the word "assign" is neither in the Agile Manifesto nor the Scrum guide. Both use the generic and not well understood term "selforganizing"

The best architectures, requirements, and designs emerge from self-organizing teams (Agile Manifesto) And from the Scrum Guide “ Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. ” “ Development Teams are structured and empowered by the organization to organize and manage their own work. ”

The best architectures, requirements, and designs emerge from self-organizing teams (Agile Manifesto) “Development Teams have the following characteristics: • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality • The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality • By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment. ”

So what does it mean to be self-organizing? It means, among others things: • Bottom up estimation and planning at least at the sprint/team level • Development Team peer pressure to balance workload (the Development Team knows who is not pulling their weight) • Overall pro-activeness from the Development Team to go after what needs to be done to achieve the sprint objective instead of waiting for task assignments. The estimation and planning process is different from the typical approach, which is to "identify tasks and hours needed " by yourself. The team should do it.

Ken Schwaber "Being managed by someone else is totally ingrained in our life and work experience. Why should we expect that when we tell a Team that it is responsible for managing itself, it will know what we are talking about? “Self-management” is just a phrase … A Team requires concrete experience with Scrum before it can truly understand how to manage itself and how to take the responsibility and authority for planning and conducting its own activities. Not only must the Scrum Master help the Team to acquire this experience, but the Scrum Master must also do so while overcoming his or her own tendencies to manage the Team. Both the Scrum Master and the Team have to learn anew how to approach the issue of management. "

The following principle from the Agile Manifesto best summarizes what is needed "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. “ The definition for the “Agile Process” • Iterative • Incremental • Self-organizing (The team has the autonomy to organize itself to best complete the work. ) • Emergent (Technology and requirements are “allowed” to emerge through the product development cycle. ) All Agile methods follow the four goals and the 12 principals of the Agile Manifesto

Agile Methods The first two are the easiest. • Iterative • Incremental The last two methods are the last mile of the Agile adoption • Self-organizing • Emergent And require from the Scrum Master a constant team education effort!

The Agile Manifesto best summarizes what is needed To "Build projects around motivated individuals” To “Give them the environment and support they need, and trust them to get the job done”