README

Agile coaching

When I coach, I rely on the principles of invitation and experimentation.

Invitation

The principle of "invitation" means that I will ask your permission before coaching you, and I'll respect your answer if you say "no" to my invitation.

If I'm hanging around your organization, it's a safe bet that somebody somewhere wants your team to align more closely with Agile values and principles. They've probably hired me to help you do that.

But just because they want you to change in a certain way, I don't assume that you will want to change that way too—not necessarily in the ways that they want anyway, and not necessarily at the pace that they want. Even if you do want to change, I don't assume that you will want my help in doing it.

I believe that everyone is capable of wrestling with their own problems. You may or may not be successful with resolving those problems, but you can and should wrestle with your problems alone if that's what you think is the best thing for you to do. This includes wrestling with the problem of meeting your management's mandates and standards around Agile.

I make my living helping people understand and apply Agile in their teams. But from my perspective, only you get to decide what "help" looks like for you, and that includes the option of you going it alone if that's what you want. It's up to you.

I am here to help you on your own terms, at your own pace, with the problems that you think are the most important for you to solve right now.

Experimentation

The principle of "experimentation" means that you should try things for yourself before deciding to make them a part of your everyday practice.

Agile has been around for a long time now. There's a lot of Agile ideas and practices out there.

But what works for other people may not work for you. That's why it's important you try out new ideas for yourself, in your own context, before committing to taking them on as part of your everyday practice.

Experimentation is easy to do. There's lots of ways I teach this skill to people, teams, and organizations. As an example, here's what the experimentation process might look like in a team that is using Scrum:

I might start by asking the team: “What do you worry about when you worry about work?”
For whatever problem that the team chooses to work on first, I ask, “What are the underlying factors that either contribute to or sustain this problem for you?”
For whatever underlying factor that the team chooses to work on first, I ask, “What are some experiments you could do that might affect that factor?”
For whatever experiment that the team chooses to run first, I help them craft a backlog item for their experiment and plan that backlog item into their next sprint. Their hypothesis for their experiment becomes the acceptance criterion of their backlog item. The outline of their experimental method becomes subtasks of their backlog item.
During their sprint, the team works their experiment to completion just like they would work on and complete any other backlog item in their sprint.
At their next sprint retro, the team evaluates the results of their experiment, then follows the above method again to help them plan an experiment for their next sprint.

I think teams should only make changes to solve problems they think are important, and they should adopt changes only after they try the new methods and prove the methods work how they want them to.

What I do as an Agile coach

As your Agile coach, I uphold and promote Agile values and principles in your organization.

I'm here to help you analyze, test, and debug your own organization through the lens of Agile ideas. When you are able to actively improve your organization using these ideas without my help, shaping your organization to your will, making your work easier, simpler, and more fun: that's when my work is done. Everything I do as an Agile coach is intended to get you to that point.

Your rights

You should have a say in the things that matter most to you.
You should have the opportunity to learn and grow.
You should know why your work matters.
You should be treated with kindness, consideration, and respect.
You should be able to do good work.

What I love to learn

I love learning how things are done. If you have a tip, trick, or technique on any subject—at work or otherwise—then let me know.

Tell me about something you love

If you have a genuine enthusiasm for anything, please tell me about it. Is it a programming language? Your family? Your pets? Hobbies?

Your enthusiasm doesn't have to be cool or exotic. It doesn't have to be "normal" either. What matters most to me is that you are passionate about it.

What do you think are the most important aspects of your enthusiasm? Why do you love it so much?

Don't assume I won't be interested. Try me!

When to meet

Please feel free to reach out and book a meeting with me on any subject at any time. I'd love to know what's on your mind.

I am at my best in the morning.

If you want to change when or how we meet, please ask. I'll be happy to accommodate you if I can.

I can flex my schedule earlier or later. I can also work late or on weekends when needed. (E.g., coming in on Sunday to set up the room for a Monday workshop that I'll be facilitating.)

That said, the Agile value of "sustainable pace" means that I aim to work for no more than forty hours per week. Beyond forty hours, my effectiveness drops off rapidly, and I don't think it's fair to charge my clients for less than my best.

Emergencies happen, of course. When they do, I'm happy to work for as long as it takes to get the job done. Note, though, that "emergencies" are rare and exceptional conditions that contrast with a normally stable environment. This is in contrast to "chaos", which is a common and ordinary state of organizational panic, churn, and dysfunction. Emergencies rate overtime; chaos doesn't.

← home