You may heard software agile/scrum team, it seems that it is based on a concept: self-organized team.

In your experience, is it possible for a team to be a self-organized? Do we need a leader/manager in such self-organized team? Any successful story or failure lessson?

tlhausmann's picture

In leaderless, task-oriented groups leadership behaviors will emerge over time. However, in my view, someone must be accountable for the results and/or reporting results of the group. Unfortunately, I cannot directly speak to experience with a scrum team...but I can speak to extensive experience with ad hoc groups formed to accomplish a specific task.

The short answer to your question is 'Yes." Different leadership behaviors (subject expert vs lead organizer, etc.) will emerge.

jtegwen's picture

I have been wondering for a lot time what the Manager Tools opinion would be on this, but I wasn't sure of a good way to ask. I'm glad you asked! 

BLUF: Self organizing is not self managing. The people on the cross functional team need to learn to depend on each other and hold each other accountable. That doesn't mean they don't have issues that management is needed to address. 
I think there's a lot of confusion about the scope of self-organizing is. Here's my take on it, YMMV. I'll use Scrum terms here to make it simpler, but it applies in similar agile situations as well. If your team is disfunctional this is much harder and needs more deft handling. 

If you're doing the scrum model at the begining of every sprint your team does sprint planning. During planning the team decides what work they can commit to for the itteration. I my mind this is primarily about two things 1) Empowerment. The team feels engaged, motivated and actually commits to finishing the work. 2) Knowledge. They ususally have the best idea of what's possible and what's not. They understand the detailed complexities of the implementation. Can they gold plate or pad the estimates/stories to make them selves look good? Of course. The Scrum Master should be working with the team on this, but they might not have the knowledge. You can work with her to help her understand when that is happening. 

Also during planning the work is not to be assigned to specific people. As the team moves through the sprint they should take on the highest priority task that they are able. How does this help? 1) People see lots of different parts of the code instead of just their one section. This gives you resiliancy for PTO/departures. 2) If someone gets delayed (personal issues, their story took longer than expected, production went down and they spent a day getting it up and recovering ,etc) someone else picks up "their story" but there isn't any polititcal stuff about it because it was never assigned in the first place. 3) The goal is to get everything done by the end of the sprint. Everyone on the team is supposed to do whatever they can to get that work done - even if it's not their normal duties. It's about getting the (cross functional) team to see themselves as a cohesive group that has what it takes to get product out the door and is responsible to do so. Which is good, because it's true. 

Self-ogranized teams are about every person on the team holding everyone else to the rules and goals of the team. We're all fallible. We all need help. It's about getting everyone to stand up and just be accountable instead of waiting for things to be handed to them. For a funtional team this is all reasonable stuff. In fact, they appreciate being acknowledged for their skills and abilities. They give more than they would if you told them what to do. If you've not read/seen Daniel Pink's book Drive I highly recommend it. A lot of agile primicples about motivation come from here. 

In this environment managers are often needed to be there removing blocks. Lots of stuff comes up to derail the team from their goals. Sometimes they're waiting on people outside the team for answers. Managers have the clout to make that happen. Managers can influence people in other parts of the organization to prevent "Drive Bys". i.e. "Hey Joe! It's Sam the Director from Sales. I've got this little feature I need to seal the deal with this big dollar client. Could you put that in real quick. It's super simple."  This "simple" feature takes 3 days.

They're also needed to help with professional development. Encourage them to go to conferences, figure out where they want to be in their career, all that stuff. Interpersonal skills are also often a place where they need management encouragement. Also, there may be times when the team presure to step up isn't sufficient. They will need your authority/relationship to solve that problemen. 

Meta: Thanks for reading this far! Dispite the length I cut out a lot of text. I'm happy to go into more detail if this novellette doesn't go in the right direction or to the right depth to answer the questions you might have. That said, I know there are other thoughts and I would appreciate hearing another approach. 


comrite's picture

Thanks for the detailed comments.

More questions:

(1) is there any readiness checklist for self-organization?

         some of team members may not be self-motivated enought to pick up challenging tasks, some of them may do not want to pick up some boring tasks? some of them are not willing to do anything extra besides already planned tasks?

          So what should we do?

(2) who is responsible for the team's performance?

        scrum team defined   PO, SM, Team roles, but no manager roles there.   Since PO/SM has no official management authority over the team, who should be hold accountable? Saying a whole team responisble for it seems to mean no one is responsible? Do you want to fire the whole team if performance is not good?

(3) In reality, there will be a manager somewhere, what is the org chart looks like if no manager role defined in the scrum team?   Who will run the scrum team? SM? PM?How manager interact with the scrum team? 



jtegwen's picture

I found this article . (which is the first in a series) It seems like a good place to start. It made sense to me and it looks like subsequent articles might help answer some of your questions, especially around readiness.
Specific answers and more pontificating are below. 
a) What do you mean when you say "not willing to do anything extra besides already planned tasks?" What do you mean by "planned tasks" and what would the "anything extra" be? 
b) Ideal state: Under performance of certain team members would be brought up in retro. i.e. "Boring tasks are not well distributed among the team". Your team might need coaching to bring up issues like this. Then the team can decide what they want to do to have a more equal distribution of work. One way you can help with this is if someone else from the team complains about someone else's behavior encourage them to bring it up in retro. Help them rephrase it to be about process not people. (like the one above rather than, “Chris doesn't ever do the boring work.”) Encourage them to hold their team mates accountable. This is easy to say and really, really hard to do.  
c) If your SM could use some support running agile retrospectives I've found the following resources massively improved my retros. There's more to retros than "What went well, what didn't go well, what do we want to change" or "stop, start, change" I'm still in the learning process myself but I'd be happy to pass on more resources I've found if that would help. 
  - Agile Retrospectives by Esther Derby and Diane  is the go to agile retrospectives guide. 
Keep the changes small. If you make 1% improvement each sprint imagine how much better they'll be at the end of 6 months! 
d) The SM should keep you in the loop on team member's progress and struggles. The two of you can come up with solutions to help coach (via feedback and 1:1s) the employees who need help. Maybe a 1:1 with the SM would help while the team is getting up and running. For the direct, they hear the same message differently from two people with different levels of authority. This is powerful. Also, the SM can say things that sound harsh coming from you. 
Real life story: 
I was working with a manager with a high S direct. She had offered help from other team mates several times. He declined and was working 12 hour days. We tag teamed him. He finally asked for the help he desperately needed. 
“Joe, I know project x set you back pretty far because of all the bugs you found and then retesting you had to do. However, the rest of the team depends on items going through QA quickly to get rapid feedback. You need to ask for help when you get behind. I know your manager would want you to do so. “ 
It turns out he was worried about overloading other people on his team. I said I knew his boss wouldn't let that happen if he asked for help. I knew all of this was true because she and I had been in consistent discussion over this issue for a week. 
a) I think the article at the top addresses this. "Self organizing teams require that each person be self organizing." Each person is responsible for their own performance. The team is responsible for bringing up issues they're having with how work gets done and related issues. 
This is in line with the MT rule that individuals perform and are evaluated. Evaluating on communication and collaboration is fair game. 
b) This depends somewhat on your organizational structure. IMO PO is responsible for ensuring that the team delivers the product that's needed on time. Some teams move this to the SM. Having the SM do this gives them conflicting roles. The SM is the advocate for the team. The PO is the advocate for the customer. 
c) If it's really the whole team that's tanking maybe it would help for the whole team to do a deep dive on what's not going right. 
d) As the manager, the SM needs you set the expectation for your people that they will step up and contribute fully. You need to set the expectation that they will do whatever needs to be done to make the product successful and provide value to the customer. 
This section assumes you're not doing work on the product. If that's not true then what is below is harder. Let me know if that's the case.  
a) Agile/Scrum/Whatever has no bearing on the org chart. Typically managers aren't in scrum teams/meetings because it stifles honest communication. "Yeah, sorry team, I really screwed that up badly." This isn't something one says easily in front of someone who has a sign on their head that says, "I can fire you." Don't attend retros. 
b) The SM coaches the scrum team. This is as close to "running the team" as scrum gets. Develop a close relationship with the SM. 
c) Managers can attend stand up. I'd talk with the SM first. Stand to the back. Makes sure no one calls on you to "give an update". 
Other general thoughts about things I think people often miss about agile. 
1) Moving to agile/scrum/whatever is really, really, really hard. It disrupts everything. It changes how everyone connected to the product works (at least). The smaller your org the more that's true. In my experience it takes 3 years to stabilize into agile - assuming you stay with it the whole time of course. :) It takes much longer than that for the whole org to adjust. Marketing often has a hard time with this. 
2) Adopt agile agilely. Try an experiment. (This is my favorite word to use, it means it's OK if it doesn't work.) Measure the changes made by the experiment. Learn. Repeat. The scientific method applies well here. Don't change too much at once or you don't know what worked. Find the greatest source of pain. Do something to improve that. Repeat. 
3) Communication is not collaboration. Collaboration is working together to achieve an end. Communication is necessary for collaboration. Collaboration is what makes agile powerful. 

jtegwen's picture

I was offline when I wrote the answer and forgot to include the link to the agile retrospectives book.

Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen