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:
- The Review should happen on the last day of the sprint.
- The Retrospective should happen on the last day of the sprint.
- The Retrospective should take place after the Review.
- There should be a break between the Review and Retrospective of at least an hour.
- The Planning should happen on the first day of the next sprint.
- 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!
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.
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.
MarComm
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......
