About self-organizing teams

Question from a budding Scrum Master, who is transitioning from a background as a traditional project manager:

“In order to promote team bonding and self-organization, 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:

1. 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
2. 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. 
3. 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 "self-organizing":

• "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."
• "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? Besides its general concept, in the context of software development 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 proactiveness from the Development Team to go after what needs to be done to achieve the sprint objective instead of waiting for task assignments. By the way notice that this ideal estimation and planning process is different from your approach, which is to "identify tasks and hours needed " yourself. The team should do it.

In a section of his book "Agile Project Management with Scrum", Ken Schwaber summarized how we tend to succumb to expecting others to make decisions that we should be making ourselves:

"Being managed by someone else is totally ingrained in our life and work experience. Parents, teachers, and bosses who teach us to self-manage instead of striving to fulfill their expectations are rare. 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 to them; it isn’t yet something real. 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 ScrumMaster 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 ScrumMaster and the Team have to learn anew how to approach the issue of management."

In essence 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."

During a meeting in the early days of the Agile Manifesto, several renowned Agile experts met (www.cs.umd.edu/~mvz/pub/agile.pdf) and came out with the following definition for an Agile process:

"Agile Methods are:

• Iterative 


• Incremental 


• Self-organizing (The team has the autonomy to organize itself to best complete the work items.) 


• Emergent (Technology and requirements are “allowed” to emerge through the product development cycle.) 

All Agile methods follow the four values and 12 principles of the Agile Manifesto."

Doing the first two is easier. The bottom two are the last mile of Agile adoption, and require from the Scrum Master a constant team education effort.”