Agile Teams Self Organize for Project Success
In my last post I wrote about the Naked Agile section of the Agile Essentials for Project Teams class. Since a critical component of any Agile project is the concept of the self-organizing team, this month I'll cover that section of the class. If you've wanted to know what a self-organizing team is and how management can create an environment that facilitates the collaborative nature of self-organizing teams, this section is for you. First, I compare the structural differences between traditional and Agile teams. In May 2011, I wrote a bit about how these structural changes can impact veteran project managers significantly. After discussing the structural changes, we turn to more logistical items, such as workspace design. I firmly believe that software development is a team sport, so maximizing communication is paramount to team success. In class, I show several examples of open environments and we discuss the types of environments student work in now and have previously worked in. A lively discussion usually ensues. Students then learn about the Satir Change Model and how organizational behavior can interfere with a team’s ability to learn and internalize self-organizing behavior quickly. For example, in my experience with large organizations, overextending team members often acts as an impediment to self-organization. Many large organizations have an accepted practice of assigning team members to three or more projects with a paper utilization rate of close or equal to 100%. Students learn how the cost of task switching and over-allocation adversely impacts team moral, performance, and learning. The section concludes with Boris Gloger’s "Ballpoint Game," which reinforces self-organizing concepts.
Next month will be the final post in this three-part series about the Agile Essentials for Project Teams class. Is there a section you‘d like me to provide more information about? Let me know and I’d be happy to oblige.