I started talking about the manager’s role in scrum as facilitating a series of conversations between the team and the larger company.

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].

Short link: http://jkat.me/mTtCA3

Tag(s): coach, individual team member, management, manager, observer, possible solutions, product owner, scrum, software development, wrong product

Comments: none

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.

Short link: http://jkat.me/gEV9LA

Tag(s): agile, coach, CTO, Executive, peer to peer, scrum, xp

Comments: 1

At Oxygen, we have a team.

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.

Short link: http://jkat.me/gFsVOe

Tag(s): agile, Bob, CEO, coach, CTO, dev director, first UX Designer, Gerry, inspiring and audacious product owner, Luke, management, software development, Steve, xp

Comments: 1

I just watched “The Heart of the Game“, a documentary about the Roosevelt Roughrider’s girl’s basketball team (my old high school).

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.

Short link: http://jkat.me/gnpgXe

Tag(s): basketball, coach, management, player, The Heart of the Game

Comments: 1

Dear consultant who uses “agile” as part of your brand,

I am a possible customer who embraces agile principles, practices agile techniques and has done so for years.

I admire the tenacity and talent it takes to build a business in consulting.

The best of you offer your clients techniques, language and a way of thinking that can better lives and turn around companies: advising them in ways to change their own organizations, bolstering their courage to experiment, helping them learn to iteratively learn, inspiring them to foster teams, empower individual contributors, incrementally improve, and helping them grow past dependency on your services.

Here’s how I judge whether a thought leader is a worthy mentor:

• Your reputation among those of your peers I know and respect.
• Do you provide context/share credit: “This is where it originated, this is who popularized or researched it, this is who’s written well on it. This is my version of it.”
• Do you espouse principles: “This is about defining work that builds equity because it offers real benefit to end users and a way of working that entrusts individual contributors of diverse talents to collaborate within teams to deliver that benefit.”
• Are you frank: “Most companies who try this fail. Most managers who try this will not change their own behavior enough to allow their teams to succeed for them.”
• Do you embody the principles: “It is about your team(s). Not me. I do not have right answers only experience, a willingness to listen, and techniques to help us figure out what you need to do to help yourselves.”

Conversely, these are the bad smells:

• Celebrating the widespread adoption of “Agile” without acknowledging most “agile” adoptions are crap.
• Celebrating scale not individual team excellence.
• Focusing on techniques not principles as if “stories” and “iterations” were magic.
• Talking about software tools before disciplined engineering practice.
• Talking about “value” and “productivity” as if a leader’s understanding of these terms were not a/the major obstacle to their workers ability to perform.
• Jamming agile practices into a contradictory way of thinking: “Agile process manager” anyone?
• Coining new jargon for a slight spin on existing practices: It looks like a timebox, smells like a timebox, tastes like a timebox. “I call it creato-inno-rations™.”
• Putting yourself above the problem: Just because you were really good when you practiced doesn’t mean you are a brilliant coach. Just because you’re a brilliant coach doesn’t mean you can do my job better than me. Just because you can do my job better than me doesn’t mean paying you to not do my job provides my company value.
• Overheated claims of personal invention/Not giving credit to others. Sorry guys (and I mean guys), Mary Poppendieck was talking kanban and software development fifteen years ago. You’ve advanced the craft, you’re changing minds, and you may be very good at what you do but you are not Archimedes.

As a potential customer, I need your honest criticism, I am impressed by your ability to learn from others. I respect determination and humility more than bravado.

Give credit where credit is due and do exceptionally well.

Short link: http://jkat.me/JpGgMv

Tag(s): agile, coach, Consultant, excellence, manager, Mary Poppendieck, organization, principle, software development, Team

Comments: none