Monday 30 November 2015

A Note on Latin Phrases

There's a tendency among some writers to think that sprinkling a little Latin - or worse, Greek - in their writing makes them look like a learned scholar.

It doesn't.

Instead, it indicates either a lack of confidence (hence the need to bolster the text with Latin to prove your erudition to yourself) or gross over-confidence (hence the need to bolster the text with Latin to prove your erudition to others).  Either way, Latin is not the right tool to prove yourself.

Reasoned argument, written in clear, concise English will always win out against stylistic flourishings that do more to highlight your self-esteem issues than your argument.  Writing is a demonstration of the clarity of your thinking; adding phrases from dead languages merely muddies that clarity in unflattering ways.

That being the case, there are of course exceptions where Latin expresses a concept far more concisely or commonly than the equivalent English.  If these expressions are in regular use, you may use them.  Otherwise you may not.  Acceptable Latin phrases in general communication are:

  • ad infinitum (if for no other reason than the equivalent "to infinity" will now inevitably be suffixed in the reader's mind by "and beyond!", which is probably not what you intended your writing to inspire)
  • ad nauseam
  • annus horribilis (but only ever for a British audience, as it is famous in these isles but not necessarily elsewhere)
  • a.d., a.m., b.c., p.m. (but never expanded)
  • bona fide (but bona fides should be left for small time American hoodlums)
  • carpe diem
  • caveat emptor
  • deus ex machina
  • emeritus
  • et tu, Brute?
  • etc (but only rarely et cetera for emphasis)
  • e.g. (but never exempli gratia)
  • in extremis
  • in flagrante delicto (but only when discussing the nocturnal activities of those who should know better)
  • in loco parentis
  • in memoriam (but only in formal writing such as an engraving or death notice)
  • in situ
  • i.e. (but never id est)
  • lorem ipsum (although this is almost a proper noun nowadays, and yes, it is Latin despite the widespread belief that it's gibberish)
  • magnum opus (but only where what you are referring to is truly such)
  • momento mori
  • modus operandi (M.O. is also acceptable)
  • non sequitar
  • N.B. (but never nota bene)
  • per se
  • persona non grata
  • post coital
  • P.S. (but never post scriptum)
  • quid pro quo
  • Q.E.D. (quod erat demonstrandum should not be used unless making a specific point in an academic or scholarly article)
  • sic
  • sine qua non (but only if you must, and only if you wish to risk pretension)
  • terra firma
  • vice versa

These may be used in general writing; in technical writing you may only ever use a Latin phrase where not only is that phrase lacking an English equivalent, but also where the phrase is common enough that it is considered to be vernacular.  156 A.D is a good example where the equivalent - "in the year of our Lord 156" - is so anachronistic as to be less understandable than the Latin.  The only time that Latin is otherwise acceptable is when your work is for the Catholic Church and only for the Catholic Church, in which case the more Latin you use the cheaper your translation costs will be. 

If there is an equivalent English phrase that is just as concise, use that.  Inter alia means "amongst other things" or "in amongst".  Both of these are as clear as inter alia and are preferred.  Similarly, exempli gratia can be replaced with "for example", whereas e.g. has the advantage of both concision and common usage. Sui generis translates as "in a class of its own" or "stands apart on merit" and either could be used instead. Tabula rasa can be replaced with "blank slate" unless actually discussing Enlightenment philosophy.

Re is a curious case where thanks to email parlance it has come to be seen simply as an abbreviation of "regarding".  As such its use in the formal sense is almost entirely unknown and therefore should be avoided in any context that is not purely communicative. Similarly, semper fi(delis) has been used so much in TV and films (thank you, NCIS) that it should be considered as reserved for United States Marine Corp personnel only.

In technical fields you can use as many Latin phrases as are proper  - cogito ergo sum, habeas corpus, in utero, primus inter pares, vox populi, etc - but again only where an equivalent English phrase does not exist, or where it does exist but does not carry the same weight of bundled meaning (the cogito being an exemplar of this). Do not use words from within these phrases out of context; there is no need to use ergo when "therefore" will suffice.

There are also many words which are so ingrained in our language that most people wouldn't take them as Latin words - agenda, circa, post mortem, versus. These may be used freely, as may titles of literary works such as Dulce et decorum est. Excelsior! may also be used, but only ironically. Proper nouns, such as Opus Dei should be treated as any other proper noun.

Any other Latin phrase (sic transit gloria mundi, vini, vidi, vici, etc, etc) should be avoided on the grounds that the majority won't understand it, and the English equivalent is perfectly acceptable.  And again, for clarity: No Latin phrases in technical documentation, except a.d., a.m., b.c. and p.m.!

Sunday 29 November 2015

What Order Should Sprint Meetings Be In?

I had an interesting conversation recently regarding the order of sprint meetings, and whether it mattered what order the review and retrospective took place.  This lead to a wider conversation about whether you could do review, retrospective and planning in only 1 or possibly 2 meetings.  That all sounded a bit "dirty agile" to me, which is normally a good cue to re-examine my assumptions to see if I've been thinking too rigidly.

In my head, the sprint ceremony order is one of the inviolable "rules" of scrum, so much so that it didn't really occur to me that people might think differently.  It's just one of the default assumptions I have about how scrum is done, rather than a subject for debate.  After discussing the matter I still don't think this is something about which you can be flexible, although this is not stubbornness so much as the lack of a compelling argument to the contrary. I'm open to persuasion if such an argument exists though.

The agile mantra of "Inspect and adapt" is high on my list of principles, so to that end I'll lay out the order of sprint meetings and why they need to be discrete meetings, and if anyone wants to chip in with counter suggestions I'm all ears.

First, the facts as I see them:

  1. The Review should happen on the last day of the sprint.
  2. The Retrospective should happen on the last day of the sprint.
  3. The Retrospective should take place after the Review.
  4. There should be a break between the Review and Retrospective of at least an hour.
  5. The Planning should happen on the first day of the next sprint.  
  6. The Planning for the next sprint should never happen until the Review and Retrospective from the previous sprint have been completed.

And now the justification for each of those points: 

1. The Review can only happen once all of the sprint stories have been completed and not before.  Therefore the Review needs to happen at the end of the sprint.  If all of the stories in the sprint have been completed before the end of the sprint then either additional stories can be added - if there's adequate time to complete them before the end of the sprint - or the team can groom the backlog, triage support requests, refactor code, and any other tasks that don't impact the sprint velocity. (If a task impacted the sprint velocity it would be story-pointed and as such be a story that was added to the sprint.) 

The Review will already be a recurring appointment in the stakeholders' calendars and as stakeholders are often in demand it shouldn't be assumed that bringing the Review forward will be simple case of sending out an updated appointment.  This is especially true where stakeholders are many and/or senior.  But this a practical objection, albeit a sensible one, and as such doesn't have the force of compulsion.  The compulsion should lie in the fact that moving the review forward serves no purpose. Assume that the Review is moved forward.  Either the Retrospective is moved forward as well or it is not.  If the Retrospective is not moved forward then moving the Review has served no purpose because the team still has to wait for the Retrospective. If the Retrospective is moved forwards as well then the end of the sprint must be moved forward, otherwise the team will have to wait for that instead.  If the end of the sprint is moved then the next sprint must be started.  This means that your sprint will start on a sub-optimal day.  Any teams working on the same sprint cycle will now be on a different sprint cycle.  The team's velocity calculations will no longer be valid.  Your customers - assuming you release an increment at the end of each sprint - will have to change their processes to accommodate a different cycle. There are other issues that will arise depending on circumstances, but all of them revolve around disturbing the cadence and rhythm of the sprint cycle. Scrum is predicated on having this cycle as part of the methodology for successful teams; there appears to be no benefit to disturbing it.

2. Assuming that the arguments for the timing of the Review ceremony hold, the same will apply to the Retrospective.  Therefore let's look at the order of the Review and Retrospective meetings.

 3. There is an argument that holding the Retrospective before the Review allows the team to deal with what went wrong and then finish the sprint on a good note with the Review where they can show off their work to the stakeholders.  I like the sentiment, but not the logic.  The argument hinges on 2 unfounded assumptions, namely that the Retrospective is all about what went wrong and therefore is a necessarily less than enjoyable meeting, and that the Review will always go well.  Neither of these assumptions stand up to scrutiny, regardless of personal experience.  That's not to say that for some people Retrospectives are a generally unpleasant experience, nor to suggest that every team has had a Review that didn't go well. But my assertion is firstly that a Retrospective should neither focus purely on what went wrong, nor be an unpleasant experience, and secondly that the assumption of future Review success based on past glories is hubris that will inevitably bite the team at some point in the future.

The long and the short of it is that the Retrospective should be honest but not unpleasant.  It's true that if you are the kind of person who doesn't take criticism well then you might not like hearing that something you were responsible for didn't go well, but frankly that's your problem and you owe your team a more mature attitude.  Likewise, if there is a team member who revels in shoving failure down the throats of their team-mates that's not pleasant either, but the group should combine to shut that person down (or in extremis remove them from the team).  Being part of a scrum team means learning and growing through an iterative process. You have to be open to that.

Likewise, Reviews can go wrong.  More importantly, they can teach you things you didn't know if you have active stakeholder participation (which you should have!). Either way, the Retrospective is where these things should be discussed and actions created.  This can only happen if the Retrospective happens after the Review.

 4. Ok, fine, we do the Review then the Retrospective.  We'll do them in one meeting and get it all out of the way, ok? No, not ok.  The Retrospective should be a separate meeting, because what comes out of the Review needs to be thought about before having the Retrospective.  Also, people work better when they've had a break, and the Review can be tiring if you've got a lot of questions to answer from stakeholders.  Give people a break for an hour or two, let the Review comments sink in, then do the Retrospective.  You'll all get more out of it that way

 5 If points 1 - 3 are assumed, then the timing of the Planning meeting becomes self-evident.  You can't complete any stories unless you've got stories to work on, and to get your stories you need to have a Planning meeting.

 6 Well, why can't we plan our next sprint if we've got some spare time? Because actions will come out of the Retrospective, and quite possibly the Review, and these should be captured in your task management system and might need to go into the next sprint.  You can groom items on the backlog, and that includes estimating story points and task time, but you won't know what the final priorities are until all of the previous sprint has been completed and the Product Owner has updated the backlog with the latest priorities.

Hopefully that explanation provides solid reasoning for you, but don't be afraid to drop a comment below if you disagree!

Sunday 15 November 2015

Why Do Some Writers Dislike Word?

There is a fair amount of disdain amongst some writers for using Microsoft Word to produce documentation of any size.  I use the word "disdain" because the people that "hate" Word normally type "Micro$oft" as a mark of how edgily anti-establishment they are (while using an iPhone).  There's no point engaging with these people in any meaningful way, because they're either teenagers trying to look cool (because all the ladies love a man who knows bash, right?) or adults who have a lot of unresolved issues (seriously, why don't women understand how cool I am???).

Very few writers actively hate Word, and when we do, it's oddly got nothing to do with whether Word is actually any good.  As it happens, even writers who use variants of SGML every single day and never go near Word will acknowledge that if you just want to whip up a one page letter then Word is the tool to use. However, that doesn't mean they'll use it to whip up a one page letter, because they're professionals.

And there it is.  That, dear reader, is the problem that a lot of writers have with Word.  It's snobbery. But before you get all hot under the keyboard and splutter indignantly in the comments, I need to contextualise that snobbery a bit. 

Word is an astonishingly polished and powerful writing tool.  I've been at this professional writing malarkey for over a decade, and in that time I've used Google Docs, Open Office, Libre, Zoho and a few others I can't even remember and none of them come even vaguely close to matching Word's functionality, intelligence and integration points.  This is especially true for Office 2013 and the desktop version of 365.  No matter how one-eyed you are about Word and it's faults - and it does have faults - if you deny that Word is the single most capable word processing tool around then you're wrong.  Fact.  It's not even a matter of opinion.  It's not like arguing about whether the Aston Martin DB9 or Jaguar F-type is the prettier car where there is room for subjective opinion, it's about plain facts.  Word can do more, do it better, and do it more intelligently than anything else out there.

So why the snobbery?  Why don't some writing professionals give Word the love it deserves?  They don't use it everyday, because there are better tools for things like single sourcing, topic based authoring and so on and so on and that's fair enough.  Word is designed to allow you to write everything from a 1 page shopping list to a 500 page book, and it will do those and everything in between very well, but it's like buying a Range Rover.  You can drive over almost any terrain in a Range Rover, and do very illegal speeds on the motorway, and be very comfortable, and fit a lot in the boot, but it's not as good as a tank off-road, or a Ferrari for high speed or a Rolls-Royce for comfort or a van for load capacity.  But it's still the best all-rounder by some distance.  That's Word.  Other writing tools offer specialist functionality, but is there a single PC user who hasn't used Word to write something at some point?  Unlikely.  And if there are, their numbers will be vanishingly small, because Word is just the best all-round package available and therefore the most ubiquitous. (There are additional reasons to explain the Office hegemony, but that doesn't change the facts about Word's pre-eminence.)

If you want to understand the snobbery about Word, it can be boiled down to that pre-eminence.  It's not the fact that Word is popular, otherwise writers would never visit Starbucks, and it's not that Word isn't the best tool for the job, because in some circumstances it demonstrably is. 

No, the reason a lot of writers don't like Word is that it's made it so easy for Billy Bob Developer to write a decent looking document that people now think technical writing is easy, and oh my God is that fricking annoying! 

No-one likes to feel that other people think their job is easy when you know that it's not.  It's fair to say that some jobs are easier than others, and some jobs require more training that others, and I'm not going to suggest that writing a help file is more intellectually demanding than writing a compiler.  But by the same token, I know someone who has written compilers, and his opinion was that writing the documentation for them was the most difficult part, because he could see everything in his head but he didn't know how to communicate it in writing.

As a professional writer, this pleases me.  I like the validation that my job is not easy for some people.  I like the fact that someone who does something I have no idea how to do considers my job the hardest part of his working day, when I find it the easiest.  It's a nice feeling.

And then along comes a bozo who thinks they can do my job because they've worked out how to add headers and footers to a Word document.

It's very easy to develop an irrational hatred of Word when you constantly hear "Can't you just whip up a quick Word document?", or "Why can't you just write it in Word?" and of course our particular favourite, "Why is it taking so long? I could do it myself in 10 minutes in Word!".  There are many, many variants of these phrases and every single one adds a small straw to the camel's back.  Eventually, the camel breaks down and from that point Word becomes "The Enemy".  So writers subtly, or not so-subtly, point out that "Of course Word is good, but as a professional I use something different", the implication of course being that using Word is fine for amateurs, but not "proper" writers.  The dislike of Word, ostensibly because it's not a professional tool, becomes a way of setting ourselves apart from non-writers.  

It's a tribal thing, and snobbery about the way that people outside of your tribe do something is a key part of all tribes. For many writers, being snobbish about using Word is an identifier that marks them as a member of a tribe they want to belong to.  It differentiates them, gives them an identity and a sense of collective, whilst letting them rail against Word as a proxy for all of the non-writers who don't understand what writers do and treat them accordingly.  It doesn't matter how good Word actually is, it matters that it's a stick that some people use to beat us with.  Or at least that's how it feels.

I'm not going to spell out the myriad reasons:

a) why Word is not always appropriate for what we do,
b) why Word doesn't have all of the functionality that we really, really, really need, and
c) why you can't do something better yourself in Word. 

If you're reading this the chances are you either know the answers yourself or at least are smart enough to know that the answers are good ones.  But next time you hear a writer railing against Word, just remember that once upon a time we were all Word fans....until it got too good.

Sunday 1 November 2015

What Are The Different Types of Writer?

Over the years I've lost count of how many times I've had to say "I don't write that kind of documentation" when someone's asked if I can write something for them.  I'm always polite about it, and I'm always willing to write it for them despite my lack of experience in that area, but nonetheless the overwhelming response is one of bemusement that I can't just magic up a document for them.  I mean, it's just writing, and you're a writer, so why can't you, you know..... write it?

Now, I'm not talking about writing where domain knowledge is a problem. That can be an issue, but in a pinch if a developer can explain something to me and I can understand it I can write some documentation if I have to, even if I don't have the domain expertise I normally try to have. No, this is people asking me to write detailed SDK documentation for a product I've never seen in a language I've never been exposed to, or a configuration guide for a technology I've never worked with, or - my particular favourite - sales literature.

*deep breath*

Seriously.  You don't hire a Ruby developer to normalise your database, or hire a mainframe guru to go heavy on JSON.  And these people work in designed, limited languages.  Technical writers operate in an unlimited, organic language in which meaning can be efficiently delivered in any number of ways.  It might come as a surprise to the ignorant (of which, sadly, there are many in the tech industry) but writers specialise just like coders do.  Yes, just like a good coder we can turn our hands to quite a few things, and we're pretty good in the areas around our specialisation, but an API writer is about as far from a marketing copy writer as a compiler programmer is from a mobile app developer. 

With that in mind, here's a quick guide to some of the main types of technical writer:

API/SDK Writers

Not the same thing, because an API is not the same thing as an SDK, but the basic skills are the same: highly technical people, writing for other highly technical people and able to read, parse and write code.  These writers are quite rare, because they need to be proficient in the language(s) you use whilst also being very good writers.  This makes them valuable; expect to pay accordingly.

Technical Product Writers

Known as "Technical Writers" in the same way as End-User Product Writers (see below) but these writers focus on things like Installation, Configuration and Integration.  If API writers are coders who can write, Tech Product Writers are IT engineers who can write. These writers have experience with enterprise systems like Active Directory, IIS/Apache, databases, and all that good structural jazz that applications use but end users never see or need to know much about.

End-User Product Writers

As above, these are just known as "Technical Writers" but rather than focusing on the people who install, configure and maintain the technical infrastructure, they focus on the people who'll actually use the application.  This means writing for different targets, from newbie data entry interns to experienced SysAdmins.  This is probably the "classic" technical writer that people picture when they hear the job title - writers of help files, user manuals, release notes, data dictionaries and so on.

End User Product Writers normally cover the biggest range and will often be the writers who cover "the rest", like knowledge base articles, FAQs, Support documentation, and anything else that is needed on the technical side of the product. Once you get further away from the product than this, you end up with....

Sales Engineering Writer

If the Sun is the product, Mercury and Venus are the API and SDK documentation, and the Earth and Mars are configuration/user guides, Sales Engineering Writing is Pluto.  That is to say, it's right on the outer fringes of what can legitimately be called technical writing.  But that's mainly because these writers work in Sales rather than Dev or Product Management or Support - i.e. places where technical people work - and so there's a certain amount of suspicion about their motives.  But hey, I run a broad church here, so I'm including them.  Sales Engineering Writers take technical concepts and put them into the simplest possible terms for Sales people to use in demos and tenders. In fairness, that's a tough job - have you ever tried to come up with an easily-understandable analogy for a self-balancing AVL tree? - because after a certain level of simplicity documentation changes from "really simplified" to "useless" and that's a fine line.


Short for Marketing Communication.  It's close, very close, or identical to a Copy Writer, depending on what company is hiring, but the essential difference is that Marketing Communication is often seen (rightly or wrongly) as being more marketing focused, especially in that social media way that everyone's pretending to love now at big companies, whereas copy writers are seen as more broadly spread over the sales and marketing gamut.  Sadly we've already got as far out as Pluto, so I can't make a Uranus joke.  

Copy Writer

A copy writer is someone who - duh - writes copy. Copy used to mean specifically journalistic writing, but over the years it now means relatively short pieces for public consumption, usually to get a specific message across. (Yes, the irony of saying that I'm not a copy writer as I write a short piece for public consumption to get a message across is not lost on me, but I'm not selling anything so it's not the same thing.) This means writing text that is designed to help pique interest in a product or service and aid sales.  Copy writing and MarComm are firmly in the Sales and Marketing domain, and are about as technical as the salespeople they work with.

Following from this, there are quite a few domain areas that writers specialise in:

  • Software
  • Medical
  • Finance
  • Aerospace
  • Rail
  • Maritime
  • Military (primarily because of the security clearance you need and the specialised writing standards they use)
These can all be broken down further, and I'm sure I've also missed some out (don't be afraid to enlighten me in the comments!), but it is further evidence that "a technical writer" is not a one-size-fits-all solution to your documentation needs.  Each of these domains is specialised enough that they will be advertised as such - "Medical Writer", "Aerospace Writer", "Finance Writer", etc - in the same way that legal jobs are advertised - "Tax Lawyer", "Criminal Lawyer", "Contract Lawyer" etc.  They might all come under the umbrella of "Technical Writer", but their knowledge, skills and experience are very varied.  The only things they have in common are great English skills and an understanding of the principles of technical communication.

This article is by no means exhaustive, but at least you can wave it at the next person that thinks that a writer is a writer is a writer.  And don't be afraid to ask them why they think technical writing is easy enough for people not to have specialities......

You Don't Need To Write Every Day

The Lone Technical Writer, aka Greta Boller, has just written an interesting article on why you shouldn't write everyday.  She suggests that writing everyday can lead to burnout, a lack of joy and an inability to separate the good ideas from the bad ones, whilst stepping back can give you perspective on what you've written, a chance to learn more about your subject and the opportunity to remember why you love writing so much.

As a professional writer with a personal blog, my attitude is similar.  I put a lot of thought and effort into the articles I write on Agile Documentation, and of the reasons that Greta gives for not writing everyday, the chance to learn more about the subjects I cover, is the prime reason I don't post more articles.  However, some people feel torn between the horns of a dilemma when it comes to writing; on the one hand they feel they are unproductive or somehow failing if they don't write every day (or at least most days), but on the other hand writing everyday often has all of the drawbacks that Greta points out.  I want to address some of the reasons for this and see if we can find a happy compromise.

To do this, let's look at why people feel bad if they don't write every day. I come from (the early days of) Generation X, the first generation for whom marriage, children, a steady career and retirement at 65 wasn't necessarily the best or most highly-regarded life choice. We in fact had many choices, and things in that area have only bloomed for the Generation Y and Millennials that have succeeded us as life's bright young things. The birth of the World Wide Web and the explosion of electronic and software engineering meant that we were the first generation to have mobile phones as essentially children - I got my first phone before I could vote - and the first generation of students who could research the vast majority of human knowledge at the click of a mouse.  This has had many benefits, but one significant drawback is choice overload.  We could see the breadth and depth of human knowledge stretched before us like a giant canvas, and so much of it looked interesting that it was, and is, hard to choose a single things to focus on for any long period of time.

This has got worse with the proliferation of interconnected digital media creation and storage devices.  How many people want to take more photographs (and organise and curate the ones they've got on multiple devices and cloud storage accounts), find new music (and organise and curate the music they've got on multiple devices and cloud storage accounts), read more books (and organise and curate the ones they've got on multiple devices and cloud storage accounts) and watch more films,  TV shows and documentaries (and organise and curate the ones they've got on multiple devices and cloud storage accounts)?  People have a voracious appetite for both learning and expressing themselves, and with so many things to explore, and so many things to get good at, how do you choose?  Whether it takes 10,000 hours to become an expert at something or 10 hours, there are still only so many hours in the day, and a finite amount of days in your life.  It is no longer possible to be a renaissance man and know everything that man knows, like Da Vinci. And on top of that, if you want to express yourself and create something, that takes time to master as well.  No-one picks up a piece of marble and a hammer and produces a Michaelangelo first time round, and no-one can write War and Peace from a standing start.

With this whirlwind of choices in mind, there are things like NaNoWriMo, National Novel Writing Month, where you write a certain number of words each day and at the end you have, if not something publishable, a serious chunk towards a publishable work. There are similar challenges with photography, film watching, novel reading, crafting, programming, language learning, and a whole host of other creative or learning pursuits.  These challenges are geared as much as anything to people who want to be personally productive and make efficient use of their time to learn, understand and create as much as they can in the relatively short life span of a human.  There are also MOOCs which can have tens of
thousands of students, and these are incredibly popular, because the drive for learning seems to be universal. This drive for learning and achieving can create pressure and lead to a feeling of failure if you're not hyper-productive all the time.  Basically, people want to be Tony Stark, or Elon Musk, or [pick your unbelievably productive hero here]. I won't go into the psychology of this - because it's presumably quite complex and highly contextual, and I'm not a psychologist - but I'm aware that it exists, and I'm aware that a lot of people suffer from this combination of intense drive and choice overload, which can often lead to feelings of failure.  If you've read this far you're probably aware of it too.

Which brings us to writing every day.  If you're struggling to write every day then NaNoWriMo won't change that.  It might change it for a month, but when a family member gets ill, or you've got a ton of housework to do, or 8 weddings, a funeral, 3 christenings and 5 birthday celebrations to attend in the space of 4 months, the fact that you spent an hour a day for 30 days working on a novel back in November isn't going to help you.  Life gets in the way.  That's normal.  Besides, at the end of that 4 month period you'll have a lot more to write about, simply because you haven't written much.  I'm not knocking challenges like NaNoWriMo at all, because they're a great way of working on your self-discipline and churning out a lot of work, but that doesn't mean that you have to work like that every day of your life to be productive.  Ah, but, I hear you say, the best way to Get Things Done is to make them a habit and do them for at least 10 minutes a day so that you can make progress!  Yes, and if you're keeping on top of your email or rebuilding an engine that productivity and project management approach is very effective, but writing is not about being efficient or getting better.  Allow me to expand on that.

There's an old saying that goes something like "If you want your child to become great at a sport, give them one ball", the idea being that you can be good at football and rugby and cricket, but you can only be great at one of them, and to that you need to specialise.  Therefore, if your child spends time playing rugby, and only rugby, they'll have a chance to be a great rugby player because they'll get better and better the more they play rugby.  As with rugby, the theory goes for some people, so with writing: Dedicate yourself to writing and you could be great at it.  But are you REALLY writing in order to get better at writing? Or are you writing to express yourself, to have a creative outlet, to give yourself a sense of satisfaction, fulfilment and achievement?  Becoming a better writer takes training, learning and effort.  That doesn't mean writing everyday, it means practising writing regularly and with a purpose.  That is not the same thing as writing a blog post or another chapter in your novel. 

I doubt many people who blog or write books do it in order to get better at writing, except occasionally as a technical exercise for reasons of professional or academic advancement. Besides, the quality of practise is more important then quantity, so writing everyday might build discipline (which is good), but it won't automatically make you a better writer.  The wheels will spin, but you won't necessarily be going anywhere.

You can apply the same logic to most creative pursuits such as music, photography, film-making, and so on.  Doing nothing but taking photos might help you develop a rule of thumb for the types of photo you take, but it won't teach you the principles of effective composition that can be used in every situation.  For that you need to learn about the theory and how to apply it. Otherwise you'll keep taking 1000 photos a day and getting 2 or 3 good ones, mainly by luck, whereas with a little theory you can take 500 a day and get 5 or 6 good ones, partly by understanding what makes a good photo.  Writing is the same.  Writing 50 pages a day of which you keep 2 is a worse use of your time than writing 10 pages of which you keep 9.

So, if I'm suggesting that writing every day isn't that worthwhile, how do you build the habit of writing and do it regularly?  Well, as this is a blog about writing in agile environments, you will not be shocked to hear that an agile approach can help.  Instead of focusing on how often you'll write, focus on what you'll produce instead.  As an example, let's look at this blog.  I know that, all things being equal, I can write 4 articles a month. So that's my velocity and sprint size right there - 4 articles a month.  The obvious way to look at this would be to say, ok, why not 1 a week then?  And the answer is equally obvious: Life gets in the way. If I'm having a busy week, or I'm ill, or work has gone crazy, I don't want this blog to suffer, but it can't be a higher priority than my work or my family, because I work to provide for my family and the blog is a personal project.  So whilst the priority of this blog is higher on my personal backlog than, say, watching a new box set, it's not higher than paid work or my family. And work and families being what they are, the chances of a week going by without me having adequate time to write an article I'm happy with are relatively high.  

But I also get weeks where everything is quiet, and that when happens I double down on the blog writing.  The important boundary is that I've got one month to produce 4 articles.  My month is a black box, and the customers - that's you, dear reader - don't care how I get the articles done within that month, you just care that they are done, and that the blog is regularly updated.

There are other benefits to an agile approach as well.  I've got a minimum marketable subset of 3 articles a month.  Less than 3 and the blog isn't updated enough for my liking, so I always do a minimum of 3 (unless circumstances are very unusual, in which case life comes first), but 4 is my goal.  A month also allows me periods of time when I can accept that my writing mojo isn't high.  If I had to write an article every week I'd have an opportunity to fail every 7 days, and sometimes my brain just doesn't work to that schedule so I'd be setting myself up for failure.  But I love writing and I know that my mojo will come back, so I know I can achieve at least 3 articles a month almost every month with a relatively small amount of effort (because I love writing, so it's not a huge effort to write when my mojo is present and correct).  A month is long enough for me to look back at my past articles and have some temporal distance to be honest with myself about what's worked and what hasn't and do a kind of personal retrospective.  It also gives me enough time to discover interesting articles (like Greta's article that made me think about this) and do a bit of planning and grooming of future articles. 

(The irony is that for the first time I've just missed my target.  I've only posted 1 article in October 2015 because it's been the busiest month I've had for several years, but I still wrote 3 articles, including this one.  It's just that I planned to post 2 articles on 31st October, but circumstances intervened and I'm posting them on 1st November instead. Despite this minor hiccup I still wrote the articles in October, which gives me confidence that the system can work even in the busiest months.)

I won't stretch the agile analogy too far, but the general concept of a sensible, repeating time period with a realistic goal at the end of it has worked very well for me, and I've started to apply variations of it to other things I want to work on. You can add goals to your monthly sprint, like "take photos of 3 sporting events", "bake 5 different cakes", "read one book", or whatever you want.  Just make sure that the things in your sprint aren't the day-to-day of email management, budgeting, cleaning, or anything else that you can use a to-do list for.  

Having tried the "build a habit by doing it everyday" approach, I can honestly say that an agile approach has made me much more productive and, crucially, stopped me burning out whilst still allowing me to build a habit.  And if I want to write every day I can. I just don't have to.  Like many people I want to read, learn, understand, create, experience and achieve many things and agile has so far proven to be the best tool to help me get there.  Go on, give it a try.  You might be surprised.