When I set out to practice and preach Agile methods, the world looked rosy to me. A team built on qualities that are human made much more sense than a team kept together by command and control. A team where everybody valued each other's individuality and uniqueness yet functioned toward one goal in an orderly manner seemed possible.
But at the runway, I realized I didn't have any wings. Why? Because stakeholders were yet to come out of the comfort zone of spreadsheets, where command and control made a lot of sense.
The first problem I bumped into concerned accountability. Our system is complex enough to be broken down into more than 20 components. People outside my team wanted to know where to go when they had a problem with one of these components. They wanted a specific person's name for each component, and I was dead against that.
For me, problems seemed a collective responsibility of the team. So if you want to keep somebody accountable, consider the team as one entity. I tried to capture the arguments both in favor and against this suggestion. Lobby 1 coined the suggestion below, and Lobby 2 (where I belong) had different set of ideas.
Suggestion: Let's have each component assigned to one person, and let's keep him or her accountable and responsible for this component.
Lobby 1's reasoning:
- This isn't against Agile practices. Though we assign names, it's not restrictive but accommodative. In other words, anybody can learn anything, but this is just for the sake of convenience.
- We don't have enough time to work on these as a team; we have to be timeboxed.
- We need quantifiable results.
- This method gives a focus and direction.
- It's difficult to create a plan when there is no single point of contact.
Lobby 2's reasoning:
- It's the team that is responsible for what is owned by the team. It's a collective responsibility.
- The team should be built on human qualities like caring, helping, and love for what one does.
- Everybody in the team should be accountable for all of the activities; there's no point in singling out somebody within the team. That goes against the philosophy.
- Learning and knowledge-sharing activities can be planned and executed like any feature update for the product. Have tasks in backlog and team will pick and do them.
- The team should be built on interactions within the team, not by processes.
After some deliberation, I managed to get majority support for a team built on the qualities outlined by Lobby 2. At this point I'm not in a position to say that I proved myself right, but I'm optimistic about the results.
But I realized one point very quickly: A self-organizing team is a goal of its own.
I have plenty of drag to work against: egos, varying experience, the culture of the organization, and "grades" that are mapped to salary, to name a few. I'm applying a few (known) practices to get thrust and momentum, namely:
- Pair programming
- Sessions that showcase learning per week
- Expressions of gratitude within team (yes, people saying thanks to each other openly)
My fingers are crossed, and I'm waiting to see the results.