Blog

Struggle with Self Organizing teams

By: David Hawks | Jan 13, 2010 |  Agile,  Article,  Team

Self-organizing teams - organizational chartI think getting teams to be self-organizing in a productive way is one of the toughest challenges of Scrum.

I remember early on in our adoption of Scrum when I was having trouble getting the teams to embrace a self-organizing culture. I brought in a trainer/coach and after careful observation, he told the management team the following:

“It is great that you guys are so curious and energetic about helping the teams, but you have to stop and get out of the way. You need to stop solving the problems for the team and let them start solving the problems themselves. Also, you need to find a way to motivate them to become curious about the process and for them to be energetic about figuring out how to be better.”

This was a huge moment for me in my progression on learning how to be a better Agile practitioner.

I think most good leaders got to where they are today because they are great problem solvers. Unfortunately, this gets in the way when are trying to encourage a Scrum team to become self-organizing. If we jump in and solve the problems, the natural tendency for the team is to let us do it (especially if we are their managers). This is the part where you have to give the team some rope and let them struggle through some of their own mistakes. This is painful to watch when you are probably confident you know a solution. You must find a way to facilitate the team through the problem without solving it for them.

Further Reading:
The Role of Leaders on a Self-Organizing Team | Mike Cohn’s
Blog – Succeeding With Agile�

Blog

What can we learn from the failure of Duke Nukem?

By: David Hawks | |  Agile,  Article

Duke NukemI just read an article about how the Duke Nukem project went on for 12 years and never released.

A comment from the article, “he did not appear to have an endgame — an overall plan for what the finished product would look like, and thus a way to recognize when it was nearing completion”

This is a common problem I see with Agile. Not having a release goal and plan. The risk of just working off of a backlog in priority order from iteration to iteration is, “when are you finished?” Some Agile advocates would say, “whenever you want to be,” however if you have a Product Owner, like Broussard in this article, who keeps wanting more and more then you may never release. Setting a goal and having a plan will help you be more disciplined and stick to it.

Full article:
Learn to Let Go: How Success Killed Duke Nukem | Magazine:

Related Posts:

Getting to Done