As good technicians we like to solve problems. That’s a good deal of the reason we got into the software business to begin with; we like to take on a problem, solve it, and see instantaneous, tangible results. Often though, what we are not good at is determining whether or not a particular problem is ours to solve. This phenomenon translates to agile teams and the broader organizations that support those teams as well. A response of “that’s not my problem” is traditionally frowned upon as being inflexible and not in keeping with the “team” spirit. But is it really?
Employing agile values and practices often makes existing organizational issues more apparent. It does not create these issues, they were there all along stuffed somewhere in the dark corner of avoidance. Agility just makes them more visible, often painfully, because to promote agility is to promote openness and transparency.
Take a common case in point. Software requirements are often pretty nebulous and not well managed. What really are the needs for a particular piece of software? What are the priorities? When is a new release called for? What should really be in it? These are not easy questions to answer. They are fraught with peril and nobody wants to get it “wrong”, or have to tell some stakeholder that his pet feature has to wait. So, traditionally real answers are often avoided and the development team is given no clear direction.
How do traditional development teams and their managers respond? Too frequently they take on the problem and solve it by making their own product requirements decisions; hoping for tangible results to follow. What follows though, is not tangible results, or at least not positive ones. What generally follows are unused product features, poor quality, bloated architectures, and a team that’s highly frustrated because whatever they do seems to be the wrong.
This is a sign a poor product management, and that is a problem for leadership to solve; not the development team. Agility relies on having engaged product management. That priorities will change is fine, and even expected; what is not fine is completing work because the development team just decides to move forward in lack of clear product management guidance.
A goal in adoption agile principles is to push accountability and decision making as far down in the organization as we can in order to get decisions made by those closest to the problem. For that to really work everyone needs to understand who is responsible for deciding what. 
I think of this as rings of decision making. Starting with the agile team itself, I want clear boundaries defined around what decisions are expected of the team; i.e., what is and is not in the team’s circle of control. I also want the team to influence decisions that are made outside of its circle of control. Influence, not make decisions. The outer rings will vary by organization, but they each have their own circles of control and their own obligation to influence those decisions made in the other rings.
While the concept is simple, the practice is not. Leadership is required at all levels to see that the right decision boundaries are in place and that decisions are being made in the appropriate rings. The boundaries need to be firm, but also flexible. As teams mature, their circle of control may grow and the boundary shifts a bit. As all of the rings work together, they may determine the boundaries need to be adjusted and do so with mutual consent and understanding.
When decisions in the outer rings are not being made however, the team needs to take a firm stand of “that’s not my problem” (perhaps stated a little more tactfully) and that has to be OK. Leadership has to both understand and support the team’s stance and then get the errant ring functioning.
| Comments |
|