Contemplating the next chapter... Or not. Photo by SA |
Ever since I first got published,
I’ve found myself pausing anytime someone asks me what I do for a living. Reason
is, I still have a day job that pays for the evening job, the writing. And
whereas you’d think it would fill me with all sorts of pride to introduce
myself as a writer, which I often do and which fills me with all sorts of pride
and joy to boot, I’m also quite proud of what I do from nine to five that
subsidises the writing. And truth be told, I rather enjoy the look of confusion
on people’s faces when I tell them what it is I that do. I am an agile coach.
What the hell is that? Agile
coach? Like in sport? You coach people? What is agile?
Sometimes I’m only too happy to
explain; other times, when I know I just can’t be bothered, I go for the much
more sexy and much less confounding ‘I’m a writer.’
But, agile. And coach. Where do I
start? Well, you might not know it by looking at me now, but once upon a time I
was a bit of a computer geek. I built my first PC, not buy, built. I rode one
hundred and something kilometres to Lagos and bought the parts, the
motherboard, the memory cards, the hard drive, the processor, the bus cables,
the casing, the keyboard… everything and a few extras. I took my treasures back
to Ibadan and built my first PC. I hooked up the 56k, dial up modem to the
phone line and presto, I had porn. Slow porn. What’s it with geeks and porn,
right? I’m no longer a geek.
So, agile coach. Well, it’s sort
of like a trainer of geeks. Agile software development, to be precise, is
simply a better way to develop software. In a nutshell, it prescribes agility.
See what I did there?
The idea is to build small,
useful parts of the big software incrementally and very quickly and release the
features once they’re ready. This way, by breaking big projects into small
useful bits, your client can start using the software, some features of it,
long before the project is completed, and feedback from actual usage will
determine what features to build next or not to build at all.
Also, because the project is
delivered in small chunks delivered fully functional in about two weekly ‘sprints’,
there is no strong commitment to features prioritised for much later in the
project. This means the client can add new stuff or remove stuff from the
backlog. Agile.
The end result is that software
built this way will contain features that the users actually want. Only about
30% of the features in big software is ever used, so why spend all that time
and money building the remaining 70%? I doubt more than 1% of the entire
Microsoft Word user population actually uses more than 10% of Microsoft Word’s
features. Never again. We’ve gone agile!
Key to this way of working is the
realisation that scope, the full set of features in a software, is not always
known or knowable, can change, and should change based on user feedback. Rather
than attempt to gather all requirements, design a mammoth software program
(Microsoft Word), build from ground up, and a few overrun-years later go live
with the brand new all singing all dancing solution, agile makes a prioritised
wish list of independent features (backlog) and delivers each feature as
quickly as possible while expecting and accepting changes to the backlog. In
the end, only what the users want gets built.
Agile lesson over, so what
exactly do I do? I help teams and organisations transition to, and become
successful at agile software delivery. Agile coach.
See why I sometimes stick to the
less difficult to explain job title of writer?
But, I’m one of those lucky few that
has two jobs that they absolutely love. I love writing, and who knew, I also
love helping people succeed. But my luck does not stop there. I have applied
agile principles to my writing and found that what works for development teams
and organisations also work for writing a novel. Let me explain.
When I’m writing a book I don’t
start with the entire plot mapped out. That is fixed scope and in agile we know
that scope should not be fixed upfront. I start instead with a general idea of
the story I want to tell, then I start with the most important part of the
story, a captivating opening, and I get that out as quickly as possible. Even
though it’s a chapter, I try to write it as a complete story with a beginning,
a middle, and an ending. A complete feature. And then I release it. Yup. I
share the chapter with a small community of friends who provide feedback in the
form of comments or the lack therefore.
Writing this way, I never know
what the next chapter is going to be until I’ve written the current one and had
some form of feedback. I don’t know what the characters will do, I don’t know
what new characters will walk onto the set, I don’t know what twists will
happen or when, and I never really know how the story will end. Take my first
novel, Easy Motion Tourist, I did not know what the ending would be until I
typed it out. Before then, the big twist was as much a mystery to me as it’s
been to anyone who’s read the book. While writing the novel I constantly looked
forward to what would happen next.
So does it work? This agile
author thing I’m proposing? Well, it’s a darn fast way to write a first draft.
By committing to no more than a chapter a day, a thirty-chapter story can be
completed in 1 month. First draft at least. I completed two manuscripts last
year and I’ve already finished one this year. But more importantly, it’s fun.
Not knowing what new shenanigans my characters will get up to, what new mess
Amaka will find herself in, not knowing how she’ll get out of it or for that
matter if she will get out of it, just makes writing a crime thriller as
exciting for me as reading one.
And this blog post I write every
other Wednesday, I write in an agile manner too. One of the concepts of agile
software development is Just In Time production, JIT. Also known as the Toyota
Production System, the easiest way to explain it is through another agile
concept of deferring decisions till the Last Responsible Moment. LRM. Put
simply, don’t do it till you absolutely have to. Not gonna say more than that ;
- )
Leye, where do I start? Having seen many clients through the enormous suffering of massive computer conversions, I think the Agile software concept is brilliant--not just for the worthiness of the computer functions, but for the productivity and job satisfaction of the people who have to work the system.
ReplyDeleteAnd then there is the feeling one gets writing a story one does not know in advance. Me, too, my friend. I find it thrilling, too.
Oh, and BTW, reading your LRM prose sits very nicely with Eric Clapton on guitar playing in the background. Not gonna say more than that. ; )
Having been a computer programmer most of my life (...er... having done computer programming most of my life... I hate to say I *AM* any particular THING :-), I'm right there with you, particularly the JIT and LRM. :-)
ReplyDeleteLeye, I wish I'd known about your agile skills when I recently suffered through a software installation debacle. Instead of JIT, the appropriate acronym for the vendor's performance was NOT...in every negative connotation of the word. Not only never on time, but bells and whistles first, substantive needs a distant last.
ReplyDeleteAbout the only positive aspect of the experience was that some inspirational murderous thoughts came out of it.
Bottom line: Thanks for showing me that there was a better way to do this ... which I shall relish passing on to my "experts" who said, "This is the way it's always done."
Did I read that right? A chapter a day? WOW!
ReplyDelete