By Christine Carron
In 2001, a group of tech folks drafted the Agile Manifesto, a set of principles that revolutionized software development. Before Agile, the accepted way to manage software projects was the waterfall method. A project would be initiated, all the requirements drafted, then coded, then tested, then put into production. Sounds logical, right?
Here’s a fun fact. When I started my career, my job was writing the requirements. I was on five different projects in four years, diligently writing requirements for mission-critical applications. Pages upon pages of requirements, all printed and organized in massive binders. Guess how many of those specced applications were ultimately put into production.
Part of the problem was the waterfall method. It was structured in a way that assumed everything was knowable at the outset—the requirements gathering phase—that no new information would be learned during the process, and nothing would (or could) change once decisions were made without tedious, contentious revisions.
Basically, the waterfall method didn’t deal with reality.
The developers who created the Agile manifesto did. The principles they outlined acknowledged the inherent uncertainty in lengthy, highly creative projects as well as the power of responsiveness and adaptiveness in such environments.
Lengthy. Creative. Uncertainty. Those are apt descriptors of a writing adventure, too.
Most of us writers are down with the creative bits of the adventure, but the lengthy and uncertainty bits? Those can be a drag.
They even lead to doubt that, if unchecked, will get in the way of us staying steady on the path of doing the work that needs to be done in order to make our writing dreams come true.
Can principles of Agile help us navigate that doubt and uncertainty? Absolutely.
If debilitating doubt is pressing on you, it will be easier to get through if you acknowledge it is there. It seems obvious, but often we can get into a space of, “well, maybe if I just ignore this, it will go away.” That is waterfall management of doubt. Not agile management of doubt.
I can tell you from years of project management experience that everything gets easier when all the cards are on the table. When we deal with what is.
So instead of thinking doubt is getting in the way of your writing, start thinking of it as part of your writerly work. Doubt will come up. You will handle it.
Reality can sometimes be bracing (to say the least,) but the moment we fully align with it, a shift happens. A relief. Instead of expending energy trying to ignore, avoid, or deny the situation, our smarts and know-how redirect to helping us move through the situation.
A key aspect of Agile is that a team focuses on smaller subsets of work at a time. Workable bits of the system start to take shape quickly, which gives the client and the team confidence that they are on the right track. It also allows them to confidently make adjustments based on what they learn as they go.
Confidence is the opposite of doubt. It is also a driver of motivation, which is why you may have noticed that in times of massive doubt, your motivation tanks, too.
The agile way to handle that? In moments of extreme doubt, focus on a small set of work you are fully confident you can land. That may be completely different work than you think you “should” be working on, or that you planned to work on. Forget all shoulds and plans when you are in extreme doubt. Progress and confidence are your goals. That is what will right the ship.
How small? As small as it needs to be. Five lines written a day. One character named. One plot point landed. When you are lost in doubt, your writing progress is of secondary importance to rebalancing your mindset.
Is your inner critic going to like this suggestion? Absolutely not. But your inner critic is not in charge of your writing adventure. You are.
So do something small you know you can do, claim the victory, and grapple yourself back into confidence one small win at a time. When you’re back in full form, you can get back to plowing through your writing work at top speeds.
Doubt comes up, for me at least, at moments of perceived failure. I didn’t get the fellowship. Another publisher rejected one of my novels. I didn’t land the revision.
Agile embraces failure. One of its tenets is to fail fast. Then a team can learn from what didn’t work and make the next iteration more effective.
Yet even in the corporate world, truly embracing “fail fast” was often a hard sell. Not in theory. Everyone was down with it, in theory. In practice, a little trickier. People were comfortable with the idea of failing fast, as long as someone else was responsible for the failure.
It took time for high-achievers to trust that failing fast was actually a successful strategy. To not actively avoid failure, or the chaser of doubt that follows, but simply to flow through it, learn, and get back to the next iteration.
That level of change takes space and grace, which I hope you give to yourself in moments of doubt.
Or if not, might be willing to do so from here on out.
Agile offers us pragmatic and compassionate ways to move through doubt and get back to making progress. Accepting the doubt is a critical first step. Then temporarily redesign your work small, prioritizing confidence. Finally, give yourself the space and grace to handle doubt differently than you may have before. Less pushing, more strategy, more smarts, more kindness.
You’ve got this!