AgileTheDocs Presentation Slides and Notes (5th Dec 2016, London)

The lovely people at GDS, in association with Write the Docs, put on a great one day mini-conference, Agile the Docs, on 5th December in London.  I was asked to present on whether documentation was in the definition of done and I was more than happy to oblige.

Without further ado, here are the slides I used, and here are the notes (I haven't done a lot of editing or formatting on the notes; the links below contain everything I talked about in a more comprehensive - and formatted - way).

If you're interested in learning more about this topic then check out the following articles:

• Should Documentation be in the Definition of Done?
• Factors that Determine if Documentation Should be in the Definition of Done 
• The Unicorn at the Heart of Scrum
• What is Water-Scrum-Fall and is it inevitable?
• Why Aren't There More Multi-Functional Teams?
  
  

Thank you to Trisha, Rosalie, Jen and Lydia from GDS, and Kristof from Writer the Docs.  You organised a short, sharp, interesting conference with interesting and diverse speakers, in a good location, at a sensible time, near a decent pub and a tube station.  Top work all round.

On a side note, the BRDC were having a benefit lunch/gala thing in the same conference centre we were, and this was parked outside:

It's an impressive machine in the flesh. And I saw Nigel Mansell in the corridor, which was pretty cool.  He looks exactly the same as he did when he won the F1 championship 24 years ago (except for the 'tashe, which went a few years back.).  Exactly the same. Either he's aged very well or he looked a lot older than his years when he was an F1 driver.

Anyway, Agile the Docs.  Really enjoyed it and looking forward to attending the next one. If you've got questions or thoughts on the presentation use the comments below or tweet me @agiledoc.

Are Technical Writers Becoming Obsolete?

When I started working in the software industry just after the turn of the century, there were Technical Writers, Document Authors and occasionally - just to spice things up a bit - Technical Authors.  All 3 of these roles did the same thing: write end user documentation that would either be printed or displayed on screen in a help format like CHM.  This documentation was aimed either at people who installed, configured and administered the software, or at users who had to navigate the UI on a daily basis to do their job.

Nowadays, every part of that has changed.  We have Information Architects, Knowledge Engineers, Content Strategists, UX Writers and "Document Wranglers" (no, me neither).  All of these roles seem to do different things, and none of them seem to have writing good old-fashioned help documentation as their primary role.  End user documentation seems to have become very passée, with little love left for a large body of writing that explains how something works. The notion of putting documentation into a .chm is scoffed at; the notion of providing a printed copy is as old-fashioned as the idea of burning your DevOps maven because she might be a witch.

Some of these changes are driven by technology.  With many applications being solely or largely online, it makes no sense to provide a .chm when a .chm is essentially just HTML, CSS and JavaScript.  There's a better, faster, more open delivery mechanism for that, and it's called a web page. On that note, as dial-up has gone the way of the phone box, there's no need to send customers the help file on a CD or on actual paper through the post.  People can download a 500 page 10mb document in a couple of seconds, although the irony is that as the documentation is delivered online using topic-based authoring, they can pick and choose what they want to see so they'd never need the whole documentation stack anyway. 

Likewise, the explosion of mobile apps and the sudden realisation that yes, good UX design IS ACTUALLY IMPORTANT (a fact that many, many companies seem to have been oblivious to pre-smart phone) has meant that a lot of small companies are letting their design do the communication for them, and the absolute minimal documentation required is in the form of prompts, labels and warnings.  These are done, if anyone does them formally, by the UX designer or a dev who's more interested or more junior than the other devs.  The mobile apps created by big companies have also forced them to realise the importance and value of good UX design, but unfortunately the completely expected has then happened: "Ooh, we didn't need a technical writer for our new mobile app because of the great design.  Let's apply that principle to our enterprise application and we can save on writers!" (This is despite the fact that their 20-million-lines-of-code enterprise application is lugging around years of technical debt and is so poorly designed that the idea of making it lightweight enough to go online is a running joke amongst the devs.  But sure, get rid of your writers, that's the problem you need to solve.)

And some of these changes have come about because it's now easier to automate some of the writer's job.  If you set up Swagger with the right templates and show a little care, your API documentation, or at least the core of it, can be provided at the press of a button.  Provide your Confluence users with well-thought out templates with mandatory fields and macros linked to JIRA, and your release documentation can be written by anyone in your team.  I would never say that these thing are enough (and I'll believe that to my dying day) but the cost-benefit ratio of hiring a dedicated writer changes with each new automation technology that chips away at the periphery of what the writer does.

However, some of these changes to the writer function are driven by methodology.  In an agile world - and if you're not agile you're very out-of-step with modernity, no matter what you think about it - the specialist is a dying and unwanted breed. No-one can be "just" a writer any more, because what we do often doesn't exist in any meaningful way now. Sure, there are plenty of massive enterprise level applications out there that need equally massive help files, but these are becoming the exception rather than the rule.  This is not helped by disruption on a grand scale from start-ups that value doing one thing really well, and a clientele of millennials who are starting to reach an age where they an have an input into buying decisions, and who are not bothered in the slightest by the idea of buying 10 different apps and using IFTTT to fit them together, rather than spending 20x as much on a behemoth from a 50 years old blue chip. 

With everyone moving to agile, the expectation is that the specialist writer can no longer be siloed into "just" writing documentation.  Hence a role like Knowledge Engineer, where you conduct the fragmentary topics to the right place to form a coherent orchestra for your audience, or Content Strategist, where you act as a lode stone to keep all of the disparate documents from different experts pointing in the same direction.  In many cases it is no longer enough to be able to write; you must be able to plan, build, guide, persuade, manage.  Writing in and of itself is almost secondary.

If you look at the coalescing of the following trends:

• Mobile apps;
• Better UX investment;
• More documentation automation tools;
• Fragmented market of smaller providers;
• Move to "specialised generalists" in agile.
  

Then you'll see that none of them are positive for the working prospects of a "pure" technical writer. It may seem that the pure skill of a technical writer - writing - is less valued than it was before, but the companies that valued this before will still value it now.  It's the changing of the technologies and methodologies that are allowing companies that never really valued documentation to do away with technical writers, and new companies that join the fray don't see the cost-benefit ratio of having a technical writer in the first place.  They hire a Content Strategist to provide a guiding strategy and write some templates, add documentation (using Swagger and other tools) to the Definition of Done, and have a Knowledge Manager to look after the internal wiki and provide light editing of the docs.  They release updates several times a week so there's plenty of scope to iteratively improve the docs as they go.  And that's it.  Where does the technical writer fit into that?  Answer: They don't.  


So where do you go if you're a technical writer?  Do you transition to analysis, QA, testing, product management, training, support, or move to a different industry altogether?  Do you keep chasing the ever-decreasing number of "pure" technical writing jobs?  Do you specialise in API and/or SDK documentation on the basis that it's one of the few areas where there aren't enough qualified writers to fill the all the vacancies?  All of these are valid and sensible options.  In the long run though, you're best off learning how to do all of the things that have been chipped away.  Learn how to use Swagger and other documentation automation tools.  Learn how text is displayed in your application and become its writer, editor and proofreader.  Learn at least the basics of UX design and join the discussions about how best to show - rather than tell - the user what to do next (because no-one is better than you at understanding that).  Become a moderator for forums that discuss your company and its products.  Learn how to manage the knowledge assets your company has.  Learn what a content strategy is and create one.  

Because being a Technical Writer is no longer enough in a lot of companies.  Eventually it won't be enough in any company. 

To Be a Good Agilist, You Need To Be a Modern Renaissance Man

During the Renaissance in Western Europe, a certain type of man came to the fore as the exemplar of what a person should be.  Whereas in the Middle Ages preceding the Renaissance a man might be a craftsman, an artist, a priest or a soldier, the Renaissance saw the birth of men who could be all these things, and more. It was not enough to be an orator, a soldier, a poet, a scholar.  A man - and it was always men - had to speak several languages fluently, be a fine horseman, write epic poetry, lead soldiers, demonstrate athletic prowess and, of course, be able to woo a lady.  Nowadays the requirements might be different (and women are no longer excluded from the education needed to be a polymath), but the intent remains the same:

"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, and die gallantly. Specialization is for insects." (Robert Heinlein)

Or to put it more bluntly:

"Single-mindedness is all very well in cows or baboons; in an animal claiming to belong to the same species as Shakespeare it is simply disgraceful." (Aldous Huxley)

What was it about the Renaissance that created men such as da Vinci, Michelangelo and Galileo?  The printing press created a relative explosion in the availability of the printed word, and with it the lifeblood of learning: knowledge.  The influx of Islamic learning (which also reintroduced a lot of Ancient Greek and Roman scholarship that had been preserved by Arabic scholars whilst the Europeans were busily destroying anything "heretical" during the Dark Ages) gave new ideas and avenues of exploration.  The Church, which over the preceding centuries had become dogmatic and corrupt, was (slowly) losing its authority both spiritual and temporal; in the middle of the Renaissance Martin Luther wrote his 95 theses about the corruption of Church indulgences and began a process that would cleave the Roman Catholic Church in two.  These events came together to provide an environment where not only was it becoming easier to find knowledge to learn from, but the overwhelming authority of the day was losing it's ability and authority to prevent people challenging the prevailing dogma.  People could start to challenge the orthodoxy of how the world worked rather than having to be content with a religious explanation that had undertones of disapproval for your temerity in even asking the question.

It's said that da Vinci was the last man to know everything that could be known (although many others have jostled for this title), partly as a sign of his brilliance, but also as a sign of how much more there is to know nowadays.  And that body of knowledge is expanding exponentially; whilst for da Vinci there was philosophy (the "natural sciences"), mathematics and art to master, for the modern human it would take a lifetime to become merely conversant with every branch of engineering, let alone a master of them.  And then there is mathematics, physics, chemistry, biology, astronomy, psychology and so on and so on, and knowledge and understanding in all of these fields is increasing every day.

But the spirit of intense curiosity that drove the Renaissance men is no more abated today than it was then.  And like the Renaissance men we are living in a time when knowledge and learning is undergoing an explosion of democratisation and availability, except this time it's the electronically printed word delivered through the internet rather than ink on a pig skin or dried wood pulp.  We may no longer have the capacity to know the full corpus of human knowledge, but we can choose to learn anything that we wish, largely for free, from the comfort of our homes.

I've made the point before that the unicorn at the heart of scrum is the multi-functional team: very desirable but largely mythical. It's largely mythical for the simple reason that it's too difficult for a person to become a master of analysis and development and testing and documentation.  It's not difficult because each of the individual elements is too difficult, but because they are all different skills with different pre-requisites and ever-increasing bodies of knowledge that you need to stay on top of to maintain your mastery.  There simply aren't enough hours in the day, assuming you have some form of personal life (and would like, in no particular order, food, recreation, relationships and sleep). I stand by this, whilst accepting that there are a few people who can master 2 of these concurrently, and very, very occasionally 3 or more.  For us mere mortals though, it's unrealistic to expect to be a 10x or full-stack developer whilst also having an encyclopedic knowledge of BABOK.

Nonetheless, that insatiable curiosity and thirst for learning that drove the Renaissance men to heights of mastery can and should be an inspiration to show that it is possible to have great knowledge in diverse areas.  There is much overlap between the functions of each profession that makes up a scrum team; if da Vinci can be both a master anatomist and the inventor of the helicopter, is it beyond the bounds of reason that a single person could be both a master of documentation AND a competent tester, or a mistress of development AND a competent analyst, or any other combination of professions in your team?  At the very least a database developer should also know the basics of web development; a technical writer should be able to write both API documentation and a Beginner's Guide and so on.

The march of the specialist has benefits for efficiency and productivity, but only the generalists can create things in a non-linear (non-conveyor belt) fashion, only generalists can see the bigger picture, anticipate how their work will affect others in their team and create and innovate within that team.  Without expecting people to master multiple professions, there is still scope for learning things that other professions do every day, even if mastery is beyond you.  

As with the Renaissance men it is no longer acceptable to say "I don't do that, I'm a developer/tester/analyst/technical writer." You can, should and must be more.

Why are Multi-Functional Teams Desirable?

In the past I've talked about multi-functional teams being the unicorn at the heart of scrum, i.e. very desirable but essentially mythical.  I've also written a post explaining my take on the reason why multi-functional teams are so hard to find, but an article from Darren Wilmshurst has made me realise that I've never talked about why multi-functional teams are desirable in an agile environment (actually, required, if you don't want to do Water-Scrum-Fall).  But before I go into this, I need to share a little bit about the writing process behind this blog, for reasons that will hopefully become clear.

Some of the posts on this blog are articulations of good practice, some of them are based on years of experience, and some of them - like this one - spring from a thought that occurs to me whilst I'm reading/writing/doing something in relation to agile.  If you've ever spent a lot of time immersed in a conceptual framework, you'll hopefully understand how everything you see and hear that has any relation to what you're immersed in has the potential to send your mind off in a direction you'd never thought of before.  This is the case with this blog; so much of what I write is the result of seeing everything professionally through the lens of trying to understand and then explain how and why agile things work the way they do, and that constantly sparks off ideas for blog posts.

Right then, that's all well and good, but what does it have to do with why multi-functional teams are desirable? Well, it's this: When I realised that I'd never written about this topic, I initially thought that it would already have been well covered in the blogosphere by other writers, so maybe I was just mentally riffing on something that has been fully documented elsewhere. This has happened before, and I didn't feel I had anything to add to the conversation, so I didn't write a post.  But in this case, maybe someone has posted extensively on this topic, but I can't find those posts.  There are posts that explain some of the practical benefits of a multi-functional team within an agile process, such as greater efficiency, less waste, cross-fertilisation of skills and ideas, and so on, and for a lot of people, maybe most people, these benefits are an acceptable end in themselves.  No more explanation is required.  But I'm more interested in articulating why those benefits are indeed benefits.  What is the conceptual paradigm behind those benefits?  What is the ground for the article of faith that says multi-functional teams are good? 

Perhaps "article of faith" is wrong, but it captures the essence of my point.  A more accurate statement might be to say that the concept of multi-functional teams has become one of the boundary conditions for what defines an agile team as agile, and, therefore, if you think agile is good, you must by default think that multi-functional teams are good.  And that makes sense, because nothing is more closely associated with agile than the concept of the multi-functional team.  Multi-functional teams are the hinge on which the agile process turns; without that team, you can't describe yourself as agile.  And yet, this boundary condition is so universally accepted without question that I can't find much written about it, which seems like an oversight to me.  I'll try to address that here.

In a previous post I talked about how agile methodologies like scrum and Kanban might be more suited to startups than mature companies.  The heart of the piece was as follows:

"As a company grows though, employees become more specialised to increase efficiency and quality.  This is an economy of scale that basically turns any suitably large company into a form of production line.  Processes, procedures and standards provide not only the structure of the company which analysts can constantly study for new ways to increase efficiency (read: profits), but also the conceptual conveyor belt along which the product passes from conception through delivery and implementation to maintenance and support.

But scrum is the antithesis of this production line ethos with its proscriptive standards and linear flow.  Scrum suggests, nay, demands a multi-functional approach to production within the scrum team, and that cannot happen if the scrum team is made up of specialists. "

Individual specialisation is the opposite side of the coin to multi-functional teams.  It is the difference between the Henry Ford production line and the farming collective.  There is an inherent tension here between the command-and-control, profit-driven efficiency of the production line, and the self-organising arrangement of a series of individual strengths and weaknesses for mutual benefit in the farming collective.  The production line values efficiency over everything, and this is why it makes sense for a startup to move towards increasing specialisation.  The key to a successful business, in the short to medium term, is to leverage a good idea such that enough revenue is generated to sustain that business as a going concern and provide enough profit for the owner to make it worth their while to continue.  The best way to leverage a good idea which you've had initial success with is to hire specialists who can design, build, support, market, sell, and so on, while you focus on the good idea you had.

But in the long term, the key to a successful business - especially in an industry as fast-moving and competitive as software - is innovation, not efficiency.  That's not to say that efficiency becomes unimportant, because it doesn't.  It's just that efficiency is only useful so far as your products are delivering what the market wants.  Even Ford, the company that made the production line famous, has the 2nd highest R&D budget of any company in the world.  Why?  Because without innovation their profits will wither and die.  Not many people want a 1980's Ford, no matter how efficiently Ford can make them, when they can have a 2015 Toyota, so Ford spends billions every year to make sure that they have a competitive range of products for people to buy, and thus ensure their long term success. 

And here's something important: innovation does not have to be mutually exclusive from efficiency.  Nor does innovation have to flout a company strategy, or a divisional goal, or have no command-and-control directing it. As long as the team that is innovating knows what their boundaries are, you can let them get on with it, like a black box.  Innovation might not be something that can be made more efficient in the way that piece work on a conveyor belt can be, but you can most definitely give a team of people the right conditions to innovate and improve their chances of coming up with the next big idea.  If you do some research on the topic, the same recommendations for creating an environment that fosters innovation come up time and again:

 - A culture of trust where people know that their ideas are valued;
 - A culture of empowerment where people won't get in trouble for trying something new;
 - A culture where the leadership actively encourages and rewards innovation.

In other words.....an Agile culture. Agile has all of these things, and although many people have to put up with working in Dirty Agile, anyone lucky enough to work in a company that has properly bought into Agile should have experienced these 3 things.  So despite initial impressions, it is the collective that values the contribution of the individual more than the production line does, and this speaks directly to why multi-functional teams are desirable:
 
The collective allows the individual the space to innovate as part of a team.  The production line just allows the individual to do the same thing they've always done, only a bit quicker.

Agile is firmly in the collective camp, and the self-organising multi-functional team is the tool that is used to drive innovation by building trust, providing empowerment, emphasising communication and fostering a culture of collective problem solving.

That's why multi-functional teams are desirable. 

This also explains why so many companies who engage in Dirty Agile don't value multi-functional teams - they are the companies without the foresight or leadership to plan for the long term, so a multi-functional team that can innovate is never as important to them as a group of specialists who can do the same thing again and again, very efficiently.  That also saves on training budgets and career development, which reduces short-term costs, although the staff turnover rate is strangely high..... I suspect that I don't need to gild this lily any further!

Perhaps you should ask yourself the question: Are you working for a company with a 1920's Ford production line, or a company with a 21st century Ford R&D department? And which one would you rather work for?

Scrum Works Better in Startups

Inspired by this article, I've been thinking about how agile works better in startups than in mature companies.  The article in question argues that Kanban is often more appropriate for startups due to the time-to-market imperative and the rapid pace of change, and I'm not disagreeing with that because a) she makes a great point, and b) I'm not going to argue with an agile maven like Abby Fichtner. 

Rather, it occurs to me that the posts I've written previously suggest that scrum is difficult to implement in practise because of the unicorn at the heart of scrum, which tends to lead towards an inevitable Water-Scrum-Fall situation.  This could imply that I think scrum doesn't work.  This is not true.  Scrum is a great methodology and although its application is hindered by the lack of multi-functional teams, that doesn't mean that it can't still be implemented well and have many benefits.

However, my experience comes mainly from working with mature products and teams, or new products and teams within mature companies.  The larger and more mature a company gets, the more specialists they employ.  No tech startup hires an agile coach as one of their first employees; it's normally 2 or 3 coders with an idea and easy access to deliverable fast food.  Agile coaches come after another developer, an accountant, a saleswoman, a marketing guy, a tester, another couple of developers, and about 50 other people, because that's the point when the company stops being naturally agile and starts needing help to understand and proceduralise the things that make them good at what they do.

In a more mature company that's got hundreds or thousands of staff you'll find increasing levels of specialisation.  In the technical writing team you might have editors, sub-editors, API specialists, tools experts, learning and education experts, and so on, on top of a pool of staff writers who actually document the output from development.  And then there's the non-technical writers who provide marketing copy, sales brochures, company reports, blog posts, social media content, and all other manner of written communications.  In a startup, the founders will do all of that as and when necessary, and as they hire staff the marketing guy will produce the marketing copy, the saleswoman will put together the sales brochure and the developers will provide some release notes or instructions on installing the product.  After that, as the company grows further, someone in development will gradually start to take responsibility for documentation and eventually become the technical writer, or the company will hire someone specifically to write it.  At that point, scrum starts to become more difficult.

In a startup, generalists are highly valued because there are many jobs to do and not many people to do them.  The founders and early employees have to do everything from development to sales to documentation to marketing to testing to paying the wages and they normally lack proscriptive standards for these things.  Therefore, an agile development methodology like scrum or Kanban is ideal: it allows them maximum agility and they are already a fully multi-functional team where the emphasis is on quick, iterative delivery.  As a company grows though, employees become more specialised to increase efficiency and quality.  This is an economy of scale that basically turns any suitably large company into a form of production line.  Processes, procedures and standards provide not only the structure of the company which analysts can constantly study for new ways to increase efficiency (read: profits), but also the conceptual conveyor belt along which the product passes from conception through delivery and implementation to maintenance and support.

But scrum is the antithesis of this production line ethos with its proscriptive standards and linear flow.  Scrum suggests, nay, demands a multi-functional approach to production within the scrum team, and that cannot happen if the scrum team is made up of specialists.
 
The more specialised the roles in your company are, the less effective scrum will be

This highlights an inherent tension that might help explain why so many companies end up implementing some version of Water-Scrum-Fall and not getting the results they expected.  Specialism - division of labour - is a clearly defined economic tool to help companies scale up their production to make it more efficient and, ultimately, increase profits.  This is one of the reasons why Waterfall is considered to be an efficient model.  Scrum is a methodology that demands generalists.  Therefore, whilst scrum can be more efficient and produce higher-quality deliverables in a small team, the staff needed for it are at odds with the staff needed for the traditional division-of-labour, process-driven methodologies.  So large companies have specialists who work in a (conceptually) linear process, but if the company tries to implement scrum they need to employ generalists that don't fit with the perceived conception of efficiency. 

In a startup though, specialisms are an anathema, and the entire company - which might be as small as 1 person - is composed of generalists who are agile by default.  Agile is not so much the right methodology for a startup to use, it's the only methodology that can be used.  Really, agile development as a methodology is the re-creation and formalisation of a tech startup mentality for larger companies, and larger companies have moved away from the generalised skill set needed to fuel that mentality in favour of a division-of-labour efficiency.  Is agile trying to recapture a mentality that's inevitably lost in the paradigm shift to being a "proper" company?  Is it possible for a large company to be agile in this way?  I'm not sure it is.

I'd be interested in hearing from anyone that seen a startup move from being a small agile operation to a larger company with increasing specialisation.  Did your company keep itself agile?  How did it do it?  Were generalists still valued as highly?  Thoughts and experiences are welcome in the comments.....

Documentation Can't Complete Until Testing Completes

To some writers, the fact that we can't complete the documentation task for a development work item until the testing task has been completed  seems so obvious that it's unworthy of explanation.  However, for those people who aren't immersed in writing documentation it isn't always so apparent.  Here's an explanation for those people.

Scrum is a methodology for cross-functional teams to produce increments of a deliverable that gradually build up into the finished product over a number of sprints.  As part of this methodology, the cross-functional team members work on the sprint backlog tasks in priority order until they are all done, and then move on to the next sprint (I've used the analogy of carnivorous beetles swarming over a carcass elsewhere as a nicely graphic image to emphasise this).  However, due to the lack of multi-functional teams (a.k.a. the unicorn at the heart of scrum) most teams end up working in some form of Water-Scrum-Fall, that is, a relatively linear progression from development to testing to documentation, done in sprints with appropriate ceremonies and artifacts***. 

In this linear situation, the developer will complete the development task, the tester will test the work, and if they find a problem they will refer it back to the developer, who will fix the problem and send it back to testing, and this process will continue iteratively until the work passes and the testing task is complete. (Some referrals might be put into the release backlog if they do not affect the acceptance criteria of the work item, but that doesn't affect the documentation in this situation). 

The reason that the documentation task cannot be completed before the testing task is completed is that it is ONLY when the testing task has been completed that no more changes will be made to that piece of work.

At this point the standard argument against you is: "Well, the developer will have followed the acceptance requirements, and wire frame, and conditions of satisfaction and [any other artifacts provided] and so the writer can complete the documentation once the developer has completed their task." 

This is true in theory, just not in practise.  Let me explain by way of an example.  The designer mandates that 4 fields need to be added in a row because users will always fill in field A, then field B, then field C, then field D.  A wire frame is produced that shows the fields as:

FIELD A        FIELD B        FIELD C        FIELD D 

At task implementation time, the developer realises that at a lower resolution these fields will not all be visible without scrolling, and, as scrolling is frowned upon, they actually put the fields as:

FIELD A        FIELD B
FIELD C        FIELD D

The tab flow goes ABCD, the natural flow is correct (for the European market where this software is sold) and it ensures that the developer has met both the user requirements and the development rules.  However, if the writer takes a screen shot at this point in time, checks that the fields do what they are expected to do as per the artifacts and sets their Documentation task to done, what happens if the tester realises that your company stopped supporting that low resolution last year, so actually it's ok for the developer to revert back to a row in line with the designer's original plan?  The developer makes the changes, the tester passes the testing task....and the documentation is wrong, but the writer doesn't know it. 

The more developers and/or scrum teams you have, the more likely it is that changes that materially affect the documentation will be made to a piece of work after the Development task has been completed for the first time. To be clear, it is NOT ok to assume or even mandate that either the developer or tester tells the writer about this, in the hope that that will solve the problem and make your team more "swarm of beetles" and less "line of ants".  Developers and testers don't know what will materially affect the documentation, so they'll have to tell the writer about lots of things that don't matter to the writer, which wastes time for all parties, and, more importantly, this puts the onus onto people to to catch and solve problems which should be prevented from ever happening by the system itself.  And that system should include writers not being able to complete their tasks before testing have completed theirs.





*** - Now, if you DO work in a multi-functional team, you can develop a piece of work and then complete the documentation task before testing having finished. But be honest, you don't work in a multi-functional team.  Don't feel bad, neither does anyone else.

Factors that Determine if Documentation Should be in the Definition of Done

When we talked about whether documentation should be in the Definition of Done, there were 6 factors that spoke directly to the answer for teams that weren't multi-functional (which is the vast majority of teams that practise scrum). That article focused on what combination of those factors would allow you to add documentation to the Definition of Done (DoD); this article looks at those factors in a bit more depth and explains why they are so important.

Let's remind ourselves of the factors which need to be looked at:

1 - Can anyone other than the designated writer(s) complete the documentation tasks?
2 - What proportion of documentation can be done quickly by the writer, e.g documenting a bug (as opposed to complicated enhancements, for example)?
3 - Is the quality of the input to the documentation tasks reliably high and consistent?
4 - Is the number of deliverables less than 2 (or if 2 or more, can they be single-sourced)?
5 - Are there proscriptive standards and templates for the documentation that is being produced?
6 - Are complicated enhancements front-loaded by the team to allow the writer to work on them as soon as possible?

Don't forget that for single- or semi-functional teams the question of whether documentation is part of the sprint deliverables is not a factor; this is about whether you can deliver documentation at the end of each sprint, and if you can't then you (or rather your company) shouldn't commit to providing documentation as a sprint deliverable.



1 - Can anyone other than the designated writer(s) complete the documentation tasks?

The answer to this question determines - for the specific purpose of working out if documentation should be in the DoD - whether the team is single-functional or semi-functional.  If there are, for example, 6 developers, 2 testers and 1 writer, and only the writer can produce documentation, the team is single-functional.  If one or more developers or testers can produce documentation to the same standard as the designated writer then the team is semi-functional. Note that adding another specialist writer to the team won't make the team semi-functional, because documentation can't complete until testing completes, so although this will provide more manpower to get the documentation done, it won't change the inherent problem that non-multi-functional teams face - the need to work in a linear process within each sprint.  If one or more developers or testers can produce documentation, they are able to take on the documentation tasks as well as tasks in their own speciality earlier in the sprint.  This is what makes the team internally agile. The more developers and testers that can produce documentation to the correct standard, the closer the team is to being multi-functional (for the purposes of providing documentation).


2 - What proportion of documentation can be done quickly by the writer, e.g documenting a bug (as opposed to complicated enhancements, for example)?

This is the key metric that determines how much work the writer can do before testing have completed their tests, and how much will have to be done after testing have completed.  The development team should provide information for each bug in the form of "This is what was happening", "This is why it was a problem", "This is what happens now". Once the developer has done this work and sent it for testing, it is rare for this information to change (i.e. testing might find an issue with the developer’s fix, but the "This is what happens now" information rarely changes), so the writer can document a bug before it's been tested and move on with a low chance of rework later on. However, if a writer is working on enhancements, especially UI changes, then there is a much higher chance that any issues found in testing will affect the documentation, therefore the chance of rework is much higher, therefore the chance of the writer completing their tasks before the end of the sprint is much lower.  For a single-functional team this proportion needs to be very high to allow documentation to be part of the DoD, otherwise documentation will be a likely point of failure when determining if a sprint completed successfully.

One thing to bear in mind:  Because of the inherent fluidity of new work and the fact that a large piece of development might be done over more than one sprint, and it is easier to document it as a whole once it’s completed (so you can fully understand it, take screen shots, work on it as one piece of work rather than task-switching all the time, etc), this factor is something to think long and hard about.  If you have a lot of enhancements to document, especially ones that tie together to make a few large enhancements, you really should opt for documenting outside of the sprint cycle, no matter what your answers are to the other factors. 

If documentation IS part of your DoD, you’ll be at the end of the accordion, and if development or testing don’t hit their deadlines within the sprint then the writer will get squeezed and squeezed until either quality or completion  - or both - become an elusive dream. And if development and testing DO hit their deadlines then they’re twiddling their thumbs for several days while you write the documentation. It’s an intractable problem that is best solved by removing documentation from the DoD and working in sprint bundles to make development and testing more efficient, and to minimize rework for the writer, but if documentation is part of the sprint deliverable then it's something that has to be managed as much as possible.



3 - Is the quality of the input to the documentation tasks reliably high and consistent?

By "high" we mean "All the information that the writer needs to document as much of the work as is possible before development and testing have completed, for example, wire frames showing the expected field positions, a complete explanation of the functionality and what it will be used for, a complete listing of all parameters that affect the new work or are affected by it, and any other information that the writer needs to provide to the customers."

By "consistent" we mean "Every work item that is in the sprint has this information in it, every time, without fail."

If the quality of the input is not both of these things then the writer will have to spend a lot more time finding the information out, which can only be done after testing have completed, and again, the writer is much more likely to fail to complete their tasks by the end of the sprint.  It's also much more inefficient in general terms; the information is all there, but the writer will have to get it manually from developers, designers, the Product Owner, etc, so this is good practise anyway.


4 - Is the number of deliverable less than 2 (or if 2 or more, can they be single-sourced)?

Deliverables might mean traditional documents such as help files and release notes, but equally it could be editing help messages and other on-screen text, writing API documentation, and so on.  The point of concern here is two-fold: Firstly, will the writer have to enter the same information in more than one deliverable in any given work item (unless it can be single-sourced, in which case the practical answer is "No") and secondly, Will the writer have to complete (format and prepare for release) more than 1 deliverable at the end of the sprint?  If the answer to either of these is Yes, then the writer has to either add the same information into multiple deliverables, or different information into different deliverables.  Either way, there is an overhead in these scenarios that adds more required time onto the documentation.


5 - Are there proscriptive standards and templates for the documentation that is being produced?

What is one of the most difficult and time-consuming things for most people to do?  Making a decision.  What is a guaranteed way to ensure inconsistent and therefore poor quality documentation? Letting people make individual decisions about formatting, language, and so on.  Having incomplete - or missing - proscriptive standards and templates therefore both costs more time AND lowers quality.  Even if a writer is good at making consistent decisions, there is still the possibility - the probability, in fact - of errors or inconsistencies being made from time to time, and as the decisions will have to be made every time they work on a documentation task there is an in-built bottleneck and inefficiency there. Anything which prevents the writer from writing should be seen as an impediment by the Scrum Master and as waste (in LEAN terminology) by the company.  So perhaps a more apt question would be: Why WOULDN'T you have proscriptive standards and templates?


6 - Are complicated enhancements front-loaded by the team to allow the writer to work on them as soon as possible?

Because documentation can't complete until testing completes and because, as noted in #2 above, there is a much higher chance of rework with an enhancement, any enhancements that require significant documentation should be front-loaded by the developers if possible.  This is not always possible, because development need to start getting work to testing, and complicated enhancements often take longer to do than bugs, so bugs get done first to ensure that testing have work to do as soon as possible in the sprint.  Bugs can also be "quick wins" for development.  There is an inherent tension here, because bugs can be normally be documented quickly (especially if the quality of the input is high and consistent and you have proscriptive standards) and also can be estimated more easily.  If you have 10 bugs left, for example, you will know that all things being equal it will take you 2.5 hours to document them (or whatever your rule to thumb tells you - mine says 15 minutes per bug as an average).  But if you have 10 enhancements, all with a different number of story points then you can still estimate them, but it's something you have to work out as opposed to being something you know.  I know that 15 minutes is enough time on average to document a single bug because over many years of experience 15 minutes has proven to be a reliable estimate for me in many different situations.  But I can only estimate how long it will take me to document an enhancement.  That estimation may be more accurate as I learn the product and participate in the grooming to properly understand the work that will be done, but I will never have the level of confidence in it that I do with my bug estimates.  The larger and/or more complex the enhancement, the less accurate your estimate will be.  And as development for a single-functional team is linear (i.e. each sprint follows a Waterfall pattern) and documentation comes at the end, it's much easier to tell if you will complete on time if you only have bugs left to document.  The more enhancements that are left until the end of the sprint to document, the greater the chance of you failing to complete your documentation tasks and being the point of failure.  This is doubly annoying because it looks like the writer has failed, but actually it's the system that has allowed the whole team to fail by not understanding what each function within the team needs, and when they need it.



Once you've understood these factors you can use them to help make your decision on whether documentation should be in the DoD.  Good luck!

Should Documentation be in the Definition of Done?

Welcome to the thorniest, most contentious question is the world of agile documentation.

If you've discussed this with many people, you'll have probably heard views that range from "Who cares?" (thank you cynical developer-types) to "It ABSOLUTELY MUST/MUST NOT be in the Definition of Done!! Anything else is madness!!!" (thank you dogmatic autodidacts) and everything in between (thank you normal people). 

So let's get one things clear from the outset: There is no objectively-right-in-every-situation answer to this, only an answer which is right for your situation.

This is why you will hear such a broad and contradictory range of opinions on the subject.  That's not to say that some of those opinions aren't correct for your situation, but what works in one scrum team situation might not work in another, even within the same department, let alone the same division or the same company.

There's a good reason that there is no one-size-fits-all answer, and it's entirely to do with the unicorn at the heart of scrum.  Truly multi-functional teams are like unicorns - very desirable and yet seemingly a myth - and as such it isn't possible for most team members to pick up any given task.  Teams range from the entirely "single-functional", where a developer can only develop, a tester can only test and a writer can only write, through "semi-functional", where, for example, some developers and writers can also test, some testers and developers can also write and some testers and writers can also develop, up to truly multi-functional, where any member of the team can pick up any task. 

For a truly multi-functional team, the decision on whether documentation should be in the Definition of Done (DoD) is based simply on whether documentation is part of the deliverable due at the end of each sprint.  If it is, then it's just another task and documentation is in the DoD, if it isn't part of the deliverable then it isn't in the DoD***. 

Outside of truly multi-functional teams though, there are several factors that need to be taken into account:

1 - Can anyone other than the designated writer(s) complete the documentation tasks?
2 - What proportion of documentation can be done quickly by the writer, e.g documenting a bug (as opposed to complicated enhancements, for example)?
3 - Is the quality of the input to the documentation tasks reliably high and consistent?
4 - Is the number of deliverables less than 2 (or if 2 or more, can they be single-sourced)?
5 - Are there proscriptive standards and templates for the documentation that is being produced?
6 - Are complicated enhancements front-loaded by the team to allow the writer to work on them as soon as possible?

(See here for a more in-depth discussion of why these things are required if you're not sure.)

For the purposes of this discussion:

    If #1 is a NO, then the team is a "single-functional" team.
    If #1 is a YES, then the team is a "semi-functional" team.

For a single-functional team:

    If #2 < 75% then documentation should not be in the DoD.
    If #2 = 75% - 85% then documentation should only be in the DoD if #3 - #6 all = YES.
    If #2 >= 86%  then documentation should only be in the DoD if at least 3 out of #3 - #6 = YES.

For a semi-functional team:

    If #2 =< 50% then documentation should not be in the DoD.
    If #2 =< 75% then documentation should only be in the DoD if #3 - #6 all = YES.
    If #2 >= 76%  then documentation should only be in the DoD if at least 3 out of #3 - #6 = Yes

If you can't answer YES to at least 3 out of #3 - #6, then for a single- or semi-functional team documentation should not be in the DoD, no matter what the answer to #2 is.  This is because those 4 questions determine whether your processes and standards will provide enough support to the writer to allow them to get the documentation done without a significant lag at the end of sprint.  If less than 3 are YES, then there are too many possible problems for the writer(s) to overcome.  (There's no absolute guarantee that a writer will face problems, but in the real-world situations to which this applies you shouldn't assume everything will be smooth sailing all the way - that's just unrealistic.)

 A note about the numbers: No sprint should be more than 80% full, to allow for contingency.  If #2 <= 85% for single-functional teams or <= 75% for semi-functional teams, then you are getting too close to using up all of your writing contingency by asking the writers to work on complicated work items that are likely to take longer, and have a higher expectation of rework if the writers works on them before testing has completed.  These figures are therefore partly a matter of logic and partly a matter of realism.  In the spirit of scrum, you should adjust them based on your own experience within a mature sprint team with a settled velocity.

You may have noticed that for both single- and semi-functional teams I have nowhere mentioned whether documentation is part of the sprint deliverable.  If you did notice, well done and gold star to you!  This is a key point: If your team does not have the skills, processes and standards in place to allow documentation to be completed in-sprint, then it should not be part of the sprint deliverable.  This is an issue that should be decided before agreeing a contract with a client. 


In summary, development is a process and some things simply have to be done in order. Agile helps with that, but, unless you have a truly multi-functional team, it doesn’t change it. Therefore, it's fair to say that to the question of whether documentation should be in the DoD, there isn’t a right answer, just answers that have varying degrees of usefulness for your situation. Hopefully the factors listed above will help you make that decision.




*** - There are other good reasons why documentation might or might not be in the DoD in this circumstance - every team, product and company is different, after all - but in principle this is the sole reason, and there's no need to muddy the waters by talking about the possible differences in business process or contractual obligations.

What is Water-Scrum-Fall (and is it inevitable)?

Water-Scrum-Fall is a compound term formed from Waterfall and Scrum. It is used to describe a situation where a company runs their development teams in an agile (scrum) fashion with scrum ceremonies, artifacts and roles, but follows a sequential waterfall or quasi-waterfall methodology both outside of the scrum team and within the scrum team itself.  The outcome for the scrum team is that each sprint becomes a mini-waterfall with lots of documentation input and a set output at the end.  In essence, it's waterfall software delivery using an incremental scrum-style release cycle rather than either a pure "big project" waterfall approach or a pure "agile prioritisation" scrum approach.

This of course is a generalisation; there is no set definition of Water-Scrum-Fall and each company that uses some flavour of it will implement it to fit their own circumstances and foibles.  But the definition above covers the basic truth of the matter.  There is a fuller explanation by Dave West, the man who coined the term, here and a short but interesting piece on the causes and the fact that Water-Scrum-Fall is a reality we have to face by the DevOps evangelist Sanjeev Sharma here.


What's interesting about these articles is that both authors focus on the business reasons for Water-Scrum-Fall, and both argue that a key factor is that the business functions outside of the scrum team are not agile, and therefore continue with their waterfall methodologies.  I don't doubt their analysis, and for the business processes and structures outside of development I'm sure they're correct, but their analysis doesn't explain why development teams continue to produce deliverables in a linear Dev-Test-Doc process within each sprint. They are missing a fundamental point about scrum that means a sequential Water-Scrum-Fall process within the scrum teams themselves is so common:

To be agile you must have a multi-functional scrum team, but multi-functional scrum teams don't exist.

Scrum is a great idea in theory, but so is the star ship Enterprise.  We can't build a functioning star ship without a warp drive, or it's equivalent, and we can't build a functioning scrum team without a multi-functional team, and those basically don't exist.  I've described this problem elsewhere as the unicorn at the heart of scrum, and in essence it boils down to this: It takes time and effort to become competent, and stay competent, at any one of the individual roles in a scrum team; it is almost impossible to become and stay competent at Development AND Testing AND Documentation AND anything else you have in your scrum team.  This is not a question of will, or training budgets, or management buy-in.  It's a question of logistics.  There's a fuller analysis of why there aren't more multi-functional scrum teams here if you want to explore this topic a bit more.


Whilst Waterfall has many flaws, it works because it takes into account the essentially linear nature of development work.  Testing can't complete until Development have completed and Documentation can't complete until Testing have completed.  Different functions can overlap, but testing cannot complete their testing of the software until development have finished development - it's a matter of physics, not choice. Development HAS to finish before testing, testing HAS to finish before documentation, and documentation HAS to finish last. This is not going to change simply by moving to a different methodology because the factor that's missing isn't methodological, it's functional. Or, more precisely, it's multi-functional. 

Water-Scrum-Fall is not caused by a failure to implement scrum correctly or completely.  It is caused by scrum being a theory that requires something that doesn't exist in the real world - a multi-functional team.  

The lack of multi-functional teams means that it is inevitable that scrum teams will move in a linear fashion, because they simply cannot operate in any other way.  If each individual member of the team is single-functional, then the testers must wait for development to finish and writers must wait for testers to finish.  Yes, of course testers and writers can use some time at the beginning of the sprint to write test plans, produce skeleton release notes, and any other tasks they can start or complete before seeing the software, but the meat and drink of their work must happen after development.  A tester cannot fully test and a writer cannot fully document without having the software.  At the end of the process, when testers are testing the last few development items, the developers have nothing to do.  When the writers are documenting the last few work items the developers and testers have nothing to do.

Let us be clear: This is a fundamental problem with the scrum theory.  There are ways of ameliorating this to a certain extent, but you cannot change the sequential nature of Dev-Test-Doc just by changing the methodology to scrum.  So if you don't have multi-functional team - and you almost certainly don't - then a linear in-sprint system is the only realistic way to operate.  This means that Water-Scrum-Fall is an inevitability for most of us, both in and out of the scrum team, and we need to find ways of making that work.


 

Why Aren't There More Multi-Functional Teams?

Multi-functional teams are The Unicorn at the Heart of Scrum - desirable, unattainable and quite possibly mythical. Why have so few people ever seen - let alone been in - a multi-functional team? Or, to put it another way, what is it about a multi-functional team that makes it so hard to create?  There are several parts to the answer:


1.  It takes a long time to master the skills to perform each task. 

Let's assume that the backlog contains development, testing and documentation tasks.  Firstly, being a competent writer can take years of training and experience, as well as aptitude.  To be a competent developer or tester you need the same.  Let's say you could master the art of creating software deliverables to a decent standard in 3 years.  Then you move on to Testing, and take another 3 years, and finally Documentation over another 3 years.  This makes the assumption that you have an aptitude for each of these areas and can pick up the skills quickly and easily, but it still takes 9 years.  That's a long time to become competent.

To make matters worse, within each of these areas - development, testing, documentation - there are specialities that require additional learning and experience.  For example, security, automated testing and documenting APIs are all specialisms within development, testing and documentation respectively.  These take additional time to learn and master.    And on top of this is the fact that each of these areas is constantly evolving with new technologies and methodologies.  You learnt about information mapping when you started as a writer, but now you need to know about DITA.  Best practise for testing plans has been significantly updated.  HTML5 is a different development paradigm to AJAX.  And so on, and so on, ad infinitum.

So it takes a long time to become basically competent in each area, and you have to constantly keep up-to-date with new developments, tools and best practises in each of these areas.  This is a difficult thing to do in 1 of these 3 areas, let alone all 3 areas, especially if you are working 5 days a week on sprint tasks.


2. How many people can really do development, testing and documentation to a high enough level?

Being a member of a multi-functional team requires each member of that team to be able to competently perform at least 2, and preferably 3, of the roles required (assuming a simple model of development, testing and documentation tasks within a sprint).  In theory this should be possible because some of the aptitudes overlap: creativity is important in both development and documentation, an eye for detail is required for both testing and documentation, a technical mindset is needed to both develop and test a piece of software, and so on. But, as someone who has worked as both a developer and a writer, I can say without doubt that development and writing are absolutely poles apart in terms of aptitude and key skills. Likewise, having asked a friend who started off as a developer and became a tester, those two trades require a very different mindset and set of talents.  Apart from technical skills, the interpersonal and soft skills for a writer need to be better than those of a developer, because a writer needs to spend time talking to developers, testers, analysts, designers, SMEs, and so on, whereas it's fair to say that the cliché of a developer who sits in a corner and never talks to anyone - and doesn't want to - is a cliché because everyone who reads this blog will have met very good developers who do exactly that.  A writer couldn't get away with that and still do their job well, but a developer can.  On the other hand, a developer who isn't comfortable with applied maths will be missing a key component of the skill set, but most writers can get away without being particularly mathematical.  There are similar difference between developers and testers, and testers and writers.

So finding people who can fulfil all of these roles at anything higher than a basic level can be difficult.


3. Do these people WANT to do all of these things?

Even if you can find several people who have all the aptitudes to be multi-functional, do they want to be?  They might not be interested in doing all of it.  Here's a cast-iron guarantee: Poll 100 developers to ask if they want to do documentation as part of their job, and 80%+ will say "No", even if they can do it and do it well.  Besides, if you spend the best part of a decade learning all of the required skills, all you have to show from it at the end is that you are a jack-of-all-trades but a master of none. Does that sound like it will provide the career progression people want? No, and especially because Scrum implementations vary from company to company, and often from team to team, so "multi-functional" can mean different things for different teams.  If you move to a team that does analysis, design and development then 2 of the 3 skills you have are not relevant, meaning you are no longer multi-functional. 

So even if you can find people who can fulfil all of these roles at a high enough level, they may not want to perform them.


In conclusion then, if your company is likely to use the same technology for a decade, AND you're lucky enough to have an aptitude for development AND testing AND documentation, AND you want to be a generalist rather than a specialist, AND you don't have aspirations of career progression outside of that team/department AND you work for a company that will allow (and pay) for the training time to get you up to speed on each of these 3 areas then congratulations, you might become a member of a truly multi-functional team.  Otherwise, you won't.  And that's why there aren't many multi-functional teams out there, and why you aren't likely to see or join one.

The Unicorn at the Heart of Scrum

The Scrum development methodology was designed to provide a flexible framework, to be used by multi-functional teams to work together to complete all of the tasks that are required to produce a functionally-ready product increment.  Each increment builds on the previous increment to eventually produce a complete solution that meets the customer requirements.  So far, so simple, and, let's be honest, quite enticing.  It's certainly a more dynamic and empowering vision than the "small cog in a big project" feeling that Waterfall provides.


But once you start applying this enticing theory in practise, most companies run up against a fundamental problem.  Scrum is deliberately designed to allow any (or at least most) team members to pick up any task that is Ready.  In this way the "multi-functional team passes the "ball" [sprint backlog tasks] back and forth on the way to the "goal line" [completion of the Sprint]".

The fundamental problem with Scrum is that multi-functional teams don't exist in practise.

Peter Measey, CEO of the agile training and coaching company Radtac, and a man with over 20 years experience of working with agile teams (agile methodologies have been around a lot longer than most people realise) once told me during a training session that he has only ever seen 1 truly multi-functional team. 1. Uno. Less than 2.  And given that no-one else I've ever met has ever seen one at all, it does seem like a truly multi-functional team is something of a unicorn - desirable, unattainable and quite possibly mythical.

I've addressed the question of why there aren't more multi-functional teams in a different post, but in brief, it's mainly because the specialisations that you need to master in each area - e.g. development, testing, documentation - are too varied, too large and too constantly evolving and updating for it to be realistic for most people to master all of them.  So if it's unrealistic to expect a multi-functional team, how does this impact your Scrum implementation?


Well, primarily it means that Water-Scrum-Fall, where jobs are done largely in a linear fashion within a sprint, is a very common implementation of Scrum.  And of course, for us writers, it means that we are at the end of the queue for work.  Testing can't complete until Development completes, and Documentation can't complete until Testing completes (which is something else I'll expand on in a later post).  So the writers sit at the end of the sprint accordion, and if development and testing don't finish in plenty of time then the writers' time to complete their tasks will get squeezed as the accordion closes and the sprint will fail.  Therefore this unicorn feeds directly in to the answers to possibly the most difficult Scrum question for agile writers: Should Documentation be in the Definition of Done?

Because of this unicorn at the heart of the Scrum theory, and to prevent the Water-Scrum-Fall problem that arises from it, it is important to recognise an important and often overlooked truth about Scrum: The power of Scrum doesn't lie in the Scrum team. Instead, the power of Scrum, and its ability to smooth the linear Waterfall-style progression within each sprint, is dependent on the following:

1. The quality and timeliness of the user stories and associated artifacts such as wire frames that are produced by analysts and designers who are working outside of the Scrum team;

2. The provision of proscriptive standards that allow testers and writers to produce skeletons and outlines for consistent testing plans and documentation deliverables, based on the artifacts and information from the ceremonies, before seeing the software.

3. The prioritisation by the Product Owner of UI elements that can be front-loaded in the sprint by development so that testers and writers can see the software as soon as possible.

4. And, most importantly of all, high quality client-company communication and constant feedback by the Product Owner to the scrum team in the form of real-time backlog prioritisation.

If these 4 elements are present then Water-Scrum-Fall can at least be made more Scrum than Waterfall, even if there will always be an element of linear progression in the absence of Scrum's unicorn.