By Nathan Donaldson
It’s been ten months since my first blog post on the Four Agile values. At the time, I was transitioning from a transient life crewing on luxury yachts back into a more grounded career in technology. Agile seemed the perfect medium between the two. Today I’d like to address responding to change over following a plan.
Agile touts collaboration and demands a high level of communication. Working with a crew of 15 to 30 people on a yacht necessitates the same. Agile says that the best way to keep your clients happy is to constantly deliver something of value. Super yachts are just one big delivery train; meals, locations, experience, pampering, attention, privacy, whatever they want, prepared and delivered on whim.
Agile all but straight out says that people need to be autonomous and trusted and supported. While I would hesitate to say a yachting crew is completely autonomous, I would counter that the best crews I’ve worked with supported each other, encouraged learning and building trust was always the goal. When I came to Boost, I thought I understood what Agile was trying to do. I was convinced that it all made sense to me.
I’ve met people who want Agile but only certain parts, people who were told they should want Agile, people who want their company to be Agile so badly but don’t think they can change it, dogmatic Agilistas constantly reminding us, patient Agilistas who listen and encourage, people who think the word Agile is synonymous with chaos and people who are Agile already and don’t know it. These are people experiencing Agile at different stages in their lives. What Agile means to them today will likely change as they interact more with the Agile community. That’s how people learn, that is how we progress.
If you were to ask me ten months ago how I would run an Agile team I would have given you a list of prescribed actions, all textbook and perfectly sound. Now, If you ask me how I would run an Agile team I’d probably give you a cheeky (but honest) answer like: I’d help them to run themselves.
I don’t think my first answer was wrong. It was what I needed to think to get to more information. It was a hypothesis. That hypothesis lead to new learning which lead to another hypothesis and so on until this moment when I think my job is to help Agile teams run themselves. This too is a hypothesis and I am testing it right now. My goal isn’t to be right about Agile, it’s to help people work together in a way that works for them. How I respond to what I’ve learned about Agile and where it will take me becomes the plan I could never have drafted from the start.
Responding to change over following a plan is a shift to listening and observing to better facilitate a goal rather than trying to control the outcome by making it live up to your expectations.
What hypotheses on Agile do you have and how are you testing them?
