Tag Archives: coach

The limits of advice – outside experts and your agile adoption

Posted on by

It takes something near wisdom to pinpoint the obstacles in your workplace.

By achieving this, you evidence rare concern to improve the work life of peers and improve their work products in ways your organization may not yet appreciate.

But having articulated a problem, you will often find no clear solution or an answer that is obvious but painful.

So you look to others for advice: peers, coaches, and thought leaders.

Don’t be surprised if the advice is unsatisfying. But this is no surprise.

Your challenges may look like a thousand examples but they are uniquely your own. At their root, they source from the people who make up your organization. People with a unique set of preconceptions, decisions, and values systems.

More essentially, you are a unique set of experiences, relationships, strengths and weaknesses and you are the essential agent for tackling this problem.

Be wary of any advice that doesn’t acknowledge this — that fails a test of respect and humility. No outside expert truly understands your situation or is deeply invested in solving it for you.

The best you can come away with is things to try, things to research, new questions to ask, analogies, fellowship and most importantly hope to persevere.

A worthy coach or advisor must approach your situation with patience and empathy. Listen and question as much as advise. Not fill the void of an answer with tangential descriptions of practice. Not pretend an answer that celebrates their abilities more than embraces your circumstances, “What you need to do…”

If you get the sense the coach or advisor is failing to listen or speaking more out of their own needs. Gleen what you can. Thank them. Move on.

But keep trying.

Don’t let the failings of the people in our community discourage you or diminish you. They are just peers with a different context. They are human too. And they are not you.

Dear agile consultant – hiring criteria for coaches and mentors

Posted on by

play at your own riskDear 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.

Closed Circle

Posted on by

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.

Team

Posted on by

At Oxygen, we have a team. Knot

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.

The Oxygen Team

The Road Not Taken

Posted on by

Mountain Path Ript - Photo by Kathie Horejsi

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.

Mountain Path Ript - Photo by Kathie Horejsi

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.