Wednesday, May 3, 2017

The Agile Author

Leye - Every other Wednesday

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 ; - )

4 comments:

  1. 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.

    And 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. ; )

    ReplyDelete
  2. 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. :-)

    ReplyDelete
  3. Leye, 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.
    About 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."

    ReplyDelete
  4. Did I read that right? A chapter a day? WOW!

    ReplyDelete