I’ve been working with teams and been a part of teams my entire work life. Not so much at university, but certainly when I started working professionally. I’ve been confused by what some people claim are self-organizing teams. To me, they don’t look particularly self-organizing. I read Brad Appleton’s excellent series of blog posts on teams. (See Self-Organizing Teams, Agile Self-Organization versus Lean Leadership, Self-Organization and Complexity, and don’t forget Resources on Self-Organizing Teams for Agility.)
I also am reading Hackman’s Leading Teams: Setting the Stage for Great Performances
I was trying to decide what to call Team A. On Team A, there are a number of specialists, who are quite happy to take items on a backlog, claim them at the planning meeting, estimate them alone, complete them alone. When a problem is reported, these folks often say, “It worked on my machine.” To me, Team A is a manager-led team. The team has not determined how to monitor and manage their own performance.
Team B is also comprised of specialists. Team B does not have a formal structure; it exists within a serial lifecycle in its silos. But the people on Team B often have lunch together, and discuss their issues over lunch. (A different form of a standup!) They tell their managers what they need to do. They have included people and excluded people from critical-path tasks. They are the ones driving the project to completion. They developed release criteria and milestone criteria. To me, Team B is a self-designing team. (Yes, that organization is lucky Team B exists.)
To move from manager-led teams to self-managing teams, there is often a transition state. I’ve been calling that state “self-directed” but that may not be the right word. (If you have a better word, I’d love to hear it.) In this “self-directed” state, the team members transition from working along to working together. They commit to the work and deliver the work as a team. But, they still don’t address their team process. They still don’t know how.
That’s where facilitative management comes in. If you are a manager and your team has managed to move past the “I own this work” to literal team work, and they don’t discover issues at their retrospectives, you need to facilitate their discovery of their problems. Maybe you throw out a question, “What would it take if we wanted to move to one-week iterations?” Or “What if we decided to use a kanban system to reduce WIP? Are our stories sufficiently small?”
If you are a team member, assess the kind of team you have. Are your managers determining your iteration duration, team makeup, who does what? You may be working in timeboxes, and you are still a manager-led team. I see a lot of agile transitions that look like this. Are you on a team who is not quite ready, as a team, to address your work processes, even though you commit to and deliver work as a team? What do you need to do or to learn to take that next step?
If you are a manager, look at your actions. Are you enabling the team(s) to work without you, or are you keeping them dependent on you? Do they need team training, that is training in how to facilitate their work as a team?
Assessing the team state is the first step in identifying a team problem. Look at your team and ask yourself, “What state is this team in, and how long has it been in this state? Is that state okay, or would we benefit from moving to another state?” Then you can ask yourself, “What can I do to help?” Now, your assessment is worthwhile.
