The Intimate Relationship Between Time and Failure
I had a great conversation tonight with some of the Women in Agile folks in Columbus. Carina Silfverduk and a handful of us are putting together a podcast, which has been really fun. We’re trying to create something succinct and focused, designed to help agilists like us maybe take some new idea back to their teams to use right away.
The theme we started with today was ‘the feeling of failure in agile’ which, for us, included a lot of related topics including psychological safety, company culture, leadership challenges, and teams with missing roles or skills. Our conversation meanders, as you might imagine, when you get four passionate agile coaches in the same room. We have a lot to discuss! This podcast episode will definitely require some artful editing to make it succinct.
After each of these conversations, I find myself energized with a lot of ideas in my own head. And one thing in particular stood out for me today. Something that I don’t think has ever occurred to me before. We were talking about “failure”, how it’s perceived, and the related challenges due to a company culture. The more we talked about it, the more the concept of time came up here and there. Failure concepts exist at all levels — corporate, organizational departments, teams of teams, and inside the teams themselves. It may be obvious, but:
The concept of failure is always completely dependent on your investment of time in relation to that event!
Missing an annual company goal is a big deal, for example, especially if you are a public company. Your department not hitting a quarterly OKR might negatively impact all of the teams there. And team members may feel like a failure for not hitting sprint goals or getting negative feedback in a sprint review. Time is important in all of those examples. Annual. Quarterly. Sprint. It’s a great reminder to think about things in context.
How much do you think about time in your agile process… in the way you work? We have to start with what we can control in our teams first. It shows up everywhere: user story estimates, cycle time for average card completion, even in the duration of our standups and sprint planning meetings.
So what can you actually do about time? Besides not wasting time in meetings, there’s something you already know to be true. The bigger the chunk of work, the bigger the risk. The risk of what? The risk of failure!
We’ve all felt this particular pain of failure. A very large user story has been in progress for over a month and then something comes up, something changes, we learn something, or we find it’s not feasible or viable. All that time was wasted. With larger amounts of time, the pain of failure increases. So, what to do is obvious right?
First of all, failure is a stigma that needs to change. You’ve likely heard that we need to replace “failure” with “learning”. While I believe it’s true, I know this is a tough culture shift to make in a lot of places. So the only way you might be able to proceed is by helping a team through doing. Break the work down smaller. Keep stories outcome oriented. Seek feedback early. And when ‘the experiments fail’, you shift course by writing or choosing different stories that take you in a new direction.
If we break stories down into the smallest pieces of work we can imagine, then we are inherently reducing our risk. The goal of every piece of work should be to do this one very powerful thing:
Discover the smallest thing you can do to learn something sooner.
We have to let go of thinking the goal of work is to “get it done”. Everyone knows now, nothing is ever done. Work should be completed iteratively. Do the smallest thing that can prove you’re on the right track. Then do the next smallest thing that improves upon the work you’ve done. Look for the earliest milestone that you might show someone your incomplete work to validate what you’re doing. The sooner you learn what NOT to do, the sooner you’ll build the right thing that matters.
Jonathan Smart, author of the book “Sooner, Safer, Happier”, does a great job explaining this concept at the Mind The Product conference in London in 2021, which is summarized in this article. He says:
Achieving big through small “requires psychological safety”, John explains, outlining the importance of “descaling the work” in order to scale agility. In a truly agile business, he explains how teams do away with upfront “bloated requirements” and instead look to experiment and learn through iteration, embracing a process which invites “intelligent failure”, leading teams to “succeed sooner”.
So I hope you and your team can plan some experiments. Find the quickest way to learn something sooner. Learn to vertically slice your stories to build tight feedback loops. In this way, you will put time on your side and have an automatic insurance policy that helps reduce risk inherently.
If you enjoyed this, please clap and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
