At key moments, the coach called a closed circle meeting where the players went off by themselves coming back with resolution or a group decision.

In the first example, the team worked through tension between players resulting in dramatically better play — going from tight games to blowing out opponents.

In the second example, the team rallied around a player at the risk of forfeiting their season.

As reward for their camaraderie and commitment, the coach made sure every player received game time during the close-fought final championship game. What’s more, the starters rallied around his decision. The younger players not only held their own but played above themselves.

There’s a lot of hype about teamwork in business and self-directed teams in agile practice. A lot of managers look to sports as an example. Rarely do we pull it off.

At the end of the day, it’s about actions that value the group as much as the individuals and actions that source from trust to earn trust.

Building this team has been the collaborative work of years.

Our CTO, Steve, made IT a strategic asset and championed a seat at the table for software development. I introduced agile principles, carved out space for agile development practices and built a product team.

Our dev director, Luke, and coach, Kris, built a disciplined XP practice. Our product team, Ilio and Suzann, and our Scrum master, Salim, built our Scrum practice.

With Luke’s lead, the team built itself by adding exceptional talents and engaging human beings. Wendy, Oksana, Lee, Robert, Daniel and our first UX Designer, Bob. Each brings experiences, specialties, passions and humor that spurs creativity in our products and simplicity, quality, and expressiveness in their underlying implementation.

For the last year, our team has included our CEO, Gerry, an inspiring and audacious product owner.

Over almost eight years together, the core of us struggled through bad practices and mediocre projects. We taught ourselves better methods and brought in great talent providing the best fit. We grew, we availed ourselves of experienced coaches, we matured, we hit our stride. Now we contribute to our field through open code, writing, presentations and mentoring.

This team is a competitive advantage. We share values, practices, and history. We have complimentary strengths, camaraderie and spirit. We are inventive, versatile and fast on our feet. Our dedication to each other is our strongest retention and recruiting tool.

I care for these individuals and I love the team we’ve created.

I began advocating agile principles at my company four years ago. Over time, my co-workers and I have grown into a Scrum/XP team. We have a track record of successful projects and a handful of supportive sponsors. Senior executives value our developers. My CTO understands the team dynamic itself is the prize asset.

Having reached a milestone on one of our larger projects and seeing ambitious work ahead, I wanted to write about how I stood at a crossroads: contribute to the team or attempt to nurture agile values elsewhere in the organization.

It’s a pleasant, contrasting choice. But it assumes a lone agile team can thrive after becoming visible to the larger organization. There are two pressing reasons why I doubt this is true:

• An agile team attacks impediments from within or without. Either the team makes progress against these obstacles or it declines.
• Human nature abhors exceptions however exceptional. If the organization doesn’t become a little more like us, it will surely, inevitably re-make us to be more like it.

So, no crossroads. One path lies before me and it looks surprisingly familiar.

As I did four years ago, I must advocate agile from within and peer to peer. This time around, I have success at my back but face longer odds.

Scrum the project. Scrum organizational change.

I can only make progress one step at a time. I must demystify what we do by allowing more chickens into my team’s reviews. I must find and coach others predisposed to agile values. I must find at least one executive willing to scrum a thorny project with their staff. If I get the chance, I must seek out expert coaching for those above and across me in the organization.

As four years ago, success relies more on others than on myself. But I believe, as before, that not trying is worse than failing in the attempt.

The first of these is the product owner and the team.

As a manager, I have to constantly remind myself I’m a chicken, not a pig. My main responsibility is to deal with issues escalated to me by my scrum master. I also coach around practices. This is often about challenging team members to find their way towards our expressed values and principles.

On occasion, I do intervene in the dev room. This is dangerous ground. Innovation springs from the ability of an organization to surprise itself. Such creativity finds its source in autonomy, accountability and necessity.

Software development doesn’t proceed down straightforward path. For each unexpected problem there is a wealth of possible solutions. Ingenuity can add wasteful complexity or differentiate and define a product. You want a team to keep momentum but you want them to think deeply.

I need my team to be open to the problems before them, purposeful and playful in devising solutions but determined to release. This takes more than good work for good wages and it’s profoundly more than good leadership from managers. Project success has to be the individual team member’s success. Tomorrow’s intellectual property is not code yet to be written, it’s the inventive potential of the coders.

If I step in therefore it should be to maintain personal investment and esprit de corps rather than to reverse any individual decision. I have a scrum master and I rely on him to maintain morale and productivity in sprint reviews and planning. Still, with my experience as a developer and unique observer role, I’ll intervene in conversations between the product owner and the team to:

• dispel misinformation
• surface contradictions
• flag intractable disagreements

Misinformation is toxic to the product and individual accountability. A misinformed team builds the wrong product. A pattern of misinformation leads a team to lose trust. They will focus on not failing in their narrow scope of execution rather than a successful business outcome. Playing safe eliminates surprise and invention and ultimately leads to failure.

Contradictions create opportunity. A solution that addresses both a value and its antithesis such as high quality and low cost can differentiate a product.

Some disagreements cannot be solved by conversation. Time and more information may resolve the conflict. Sometimes disagreements simply need to be acknowledged. In the spirit of “any decision is better than no decision”, the product owner or scrum master needs to be encouraged to move in one or other direction despite dissensus in the team.

All of this assumes the project in question is healthy. Intervention into a troubled project is a different animal [see my earlier post on stopping the line].