From the Agile Manifesto:
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
There are times when you can't be in the same room as some or all of the rest of your team to have that face-to-face conversation, so how can a writer work as part of a team remotely?
Let's get one thing clear: Agile can and does work with remote team members. This applies to writers as much as developers, testers, designers, etc. In theory even a scrum master could be remote (although that might be one of those times when theory and practise diverge). I'll explain how this can work, but nothing beats practical experience and as a manager of writers I've managed all 4 of the possible scenarios:
- Local writers working with local teams;
- Local writers working with remote teams;
- Remote writers working with local teams;
- Remote writers working with remote teams (i.e. a worker who is not working in the same geographical location as me and nor are they working in the same location as their scrum team, who were based in a different geographical location to mine).
I know that all of these scenarios can work for writers, because I've managed writers who have been successful and productive members of scrum teams in all of these scenarios. There's no doubt in my mind that the simplest and most effective situation is for all team members to be in the same location, and preferably the same office space***. But there are often good reasons why one or more members of a team will be working remotely, and, if you are the remote worker, it is your responsibility to find ways to be an effective member of the team. It is the responsibility of the rest of the team to help you be effective.
The following lays out the most important things for being an effective remote worker in a scrum team over a period of time:
1 - Communication
2 - Trust
3 - Availability
4 - Clarity of goals
Before we look at these in more detail, it's worth emphasising that if you haven't worked with all of the remote team members before, then face-to-face meeting at the start of the process can be very helpful. Putting a face to an email signature and having an idea of them as a living, breathing person can make faceless communication much less fraught. It’s very easy to read the wrong intentions into written communication, especially if you don’t share a common native language and/or culture. Meeting people can prevent a lot of that kind of problem by giving you a sense of who they are as people - remember that most communication is non-verbal, so you'll get far more out of a 30 minute meet-and-greet than you will out of a month's worth of dialling in to conference calls.
If meeting the team in person isn't possible for whatever reason, try doing virtual face-to-face meetings using video conferencing. Introduce yourself, ask questions about what each team member does, what they need from you and what you need from them. This will at least give you some kind of baseline to work from, because you don't want your first person-to-person contact with a team member to be at a moment of stress or pressure.
Assuming you've met your team either in person or by video, lets look at the 4 key areas in more detail.
Communication
Clear, agreed lines of communication are key when working in an scrum team. By working remotely you're giving up one of the biggest assets that a scrum team has - regular face-to-face communication within the team - and as such you must agree on methods and systems for replicating this as much as possible. The obvious tool is video conferencing, and it should be a matter of course that you attend all ceremonies using this tool. But over and above these set-piece meetings, use instant messenger, email, Slack, Hangouts, or whatever combination of tools that works for you and your fellow team members, and use them a lot. Part of being a remote worker is making sure that your team remembers and includes you, and if you've never worked remotely before you might be surprised by how easy it can be to feel, or be, forgotten. Regular (at least daily) contact with your team outside of the set-piece ceremonies will help you keep in the loop, and help your team mates keep you in the loop, and nothing is more important for an agile team than everyone knowing what is going on.
Trust
My experience of managing writers is that a good member of staff is good regardless of whether they are working remotely. I appreciate staff who are pro-active, good at gathering information, independent and who know when they need to involve me and when they don't, and that is the same for both local and remote workers. Unsurprisingly, these skills are also key to being an effective member of a scrum team, especially if you work remotely and you don't have a long history with your team. You can't assume that your new team will have an immediate level of trust in you and your work, because until you've proven it - and they've proven the same to you - you're all still finding your way.
It's only once the team's velocity has stabilised that the team as a whole will have a good feeling for which team members have what strengths and weaknesses. The developer who's not the quickest at getting their task done, but who is the social glue that holds the team together, provides a value over and above just their output; as a remote worker, you don't have this kind of opportunity to provide additional value because you're not in the office with the rest of the team. Therefore your team mates need to trust the quality and quantity of your output, and your contributions to meetings - those are your core competencies and you will be judged on them. That can feel a bit harsh sometimes, but one of the downsides of remote working is that your lack of physical presence gives the rest of the team less day-to-day evidence on which to evaluate your contribution, so make your contributions regular and high-quality!
Availability
If there is a particularly annoying problem when dealing with remote workers, it's that they aren't working when you are, so you can't get hold of them. This is really, really irritating because they have become an impediment to your work, and as they are part of the same scrum team that should not be happening, even if they are part-time or working in a different time zone.
To be clear, I'm not saying that people who work part-time or in a different time zone are a impediment to the team. What I am saying is that the team should know when someone will be available so they can plan accordingly. If I need something from a part-timer who works 10am - 2pm 5 days a week, then I can just ask them on any given day during that time slot. That's not an impediment because I know when they will be available. Similarly, if I work 9am - 5pm and a remote worker in a different time zone works the equivalent of 11am - 7pm, that's also not an impediment because I know I can contact them between 11am and 5pm. The impediment is the uncertainty of when I can and can't get hold of a team member.
To remove this impediment, try instigating a block of core hours – e.g. 11am – 2pm - when people will always be available for ceremonies, conference calls, IM/email exchanges, etc. This gives everyone the flexibility at the beginning and end of the day when you aren’t expected to answer immediately, whilst still providing a standard block of time each day to ask questions, get answers, have meetings, etc. This will help with planning and time management, and remove the impediment of uncertainty.
An additional remedy is making sure all calendars are shared, either by sharing individual calendars or, preferably, having a team calendar where everyone adds in their holidays, booked meetings, and so on. This provides a central location for remote and local workers to easily find out when a person they need will next be available.
Clarity of goals
There are short term and long term goals that the whole team should be working towards. The short term goals will normally be sprint and release based, so it is important to clarify up front what deliverables are included in the Definition of Done for both the sprints and the release. This is even more important if you're working remotely because the assumption for a remote worker is that they tend to be slightly more autonomous, especially if they are a contractor and/or non-developer.
For the long term, try to build a common goal and sense of direction between both teams. Meeting face-to-face helps build the required trust to work as a team; having a shared, agreed goal helps that team have a focus. In general terms, it’s about developing strong relationships quickly and making sure you’re all pointing in the same direction. Again, as a remote worker this is particularly important.
What else do you think is important when you're providing documentation remotely for a scrum team? Sound off in the comments!
Update: Content curator, blogger, entrepreneur and all-round high-achiever Belle Beth Cooper has put together a stupidly good guide to remote working which I can't recommend highly enough. If you want more articles, Belle has kindly added a section at the end of the guide with her recommendations.
*** - The caveat is that some people prefer to be on their own for periods of time, and
suitable allowances such as private offices (where available) should be
made for that, but they should still be easily reachable.
In my previous post, I talked about documentation having technical debt. Normally this debt is a burden on the users, and therefore the customer support team (this is one of the reasons why documentation has value, rather than just a cost, but I'll expand on the benefits of documentation in a future post). But technical debt in the software, whilst potentially being a burden on customer support - and indeed customers - can become a big burden on documentation, and lead to more technical debt in the documentation itself. Allow me to clarify.
If your software:
- Does something when it shouldn't do;
- Doesn't do something when it should do;
- Does something in an unexpected way;
- Does something in an incorrect way;
- Is unnecessarily complicated;
- Is not designed with ease-of-use in mind;
- Causes an unnecessary manual intervention;
- Causes an unnecessary manual correction;
- Causes the user any problem that requires them to contact Customer Support;
Then
your software has technical debt that should be explained in the
documentation. That's a whole bunch of known issues that have to be
documented in at least one place, and maybe more (for example, on a
dynamic customer-facing website and also in the release notes), as well
as additional documentation effort required to talk the users through
bad design or bad implementation. This is a burden on the documentation
team. In a very real sense, development's debt is therefore
documentation's debt, because we (are one of the teams that) have to pay
the interest on that debt until it is paid in full by development.
On top of this, the additional documentation that has
to be done has to be recorded and monitored, so that as the development
team pay back their debt in code, we can amend our documentation to
match. As soon as this happens, there is a technical debt in the
documentation, because it no longer matches the software. This debt may
only last until the writer has completed the documentation task that go
with the development task, or, as happens more than it should, a
developer might see and fix something whilst they are working on the
code line but not mention it because they didn't realise it was
documented anywhere, and the documentation debt never gets paid.
A simple example might be that the
documentation states that a process may take some time if there is >=
10000 records. A developer is working on fixing an unrelated issue in
this process, and whilst she's in the code she realises that a minor
change to a While loop will speed up the process significantly,
especially for larger record sets. She makes this change, as well as
fixing the unrelated bug, documents the bug fix (but not the speed
change), and moves on to the next task in the backlog. Bang, your
documentation is now incorrect, and there is no way you'll ever know
about it. Meanwhile, your customers "know" that this process is not as
fast as it should be, and this decreases their satisfaction with your
product. This is a small error in your documentation, and the
customer's satisfaction decrease is equally small, but if you multiply
this by 10, or 20, or 50 small errors then their cumulative weight can
make your documentation seem inaccurate and your product quality seem
poor.
The other large burden that technical debt can place on
documentation is when the software is unnecessarily complex. A friend
of mine once described a product he worked on as suffering "death by a
thousand parameters", as every piece of additional functionality that a
customer wanted was parameterised so that the other customers could
continue using the product in their own way. This led, as you can
imagine, to a ridiculously complicated system, and was caused entirely
by an unwillingness to say no to shouty customers, and an equal
unwillingness to make long-term strategic decisions that would benefit
the majority of customers instead of just the most obnoxious
complainers. The fate of this product was entirely obvious to all but
those who's unwillingness led it to its inglorious endpoint. This
situation is a somewhat extreme example, and I suspect it's particularly prevalent in a Dirty Agile situation where the Product Owner is
not the hawkish gatekeeper they should be, but it casts a light on a
problem that writers face in many companies - the expectation that
technical debt has been "dealt with" as long as someone has documented
it.
I don't know how to say strongly enough that this is wrong, but maybe Scott Adams can help:
 |
| 'Nuff said.... |
That kinda sums it up right there. The scary thing is that some people need that explained to them, or they see the superficial humour but don't see it as a genuine problem that needs solving. If as a writer you find yourself spending any significant time writing documentation to cover the technical debt of your software, then that software will be unlikely to provide you with a long term career. No company with any pretensions to success will have that level of debt in their products, because they won't get the confidence of their customer base, and without that confidence they won't make the sales that will sustain the company in the long term. On top of that, the cost of maintaining a product with significant technical debt is much higher than the cost of maintaining a product with low levels of technical debt, so you get the double whammy of low customer confidence leading to low sales income on the one hand, and high maintenance cost on the other. Hopefully you don't need to be a business guru to work out the consequences of this....
"Technical debt" is a concept in programming that describes all of the work that has to be done later because it wasn't done (or done right) at the time. Wikipedia sums it up nicely:
"The debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy [software complexity]."
A solid overview of technical debt in software projects can be found here. That link details the technical debt experienced within the code line, which is the common understanding of where such debt accumulates.
However, the following issues are also a form of technical debt for your documentation:
- A backlog of documentation tasks (where documentation is not in your definition of done).
- Known errors in your documentation.
- Known omissions in your documentation.
- Known ambiguities in your documentation.
- An out-of-date Table of Contents or index.
- A lack of consistent terminology and/or use of standards within a document.
- A lack of consistent terminology and/or use of standards within a documentation suite.
- A lack of consistent terminology and/or use of standards across different documentation suites.
- Documentation that is out of sync with the most recent release.
- Missing documentation (e.g. you have installation notes but no configuration guide).
- Multiple documents that could (and therefore should) be single sourced.
There are other types of technical debt for documentation; these points should be thought of as examples, rather than as an exhaustive list. As all technical debt is shared by the whole team, our debt is their debt and vice versa. I'm sure you can imagine that there is some contention about whether documentation is included in the "official" definition of technical debt, but that largely boils down to whether or not documentation is included in the Definition of Done, which I've discussed elsewhere.
The important point is that, like a software application, a large piece of documentation can be very complex, and the more errors or omissions there are, and the earlier these occur, the more you pay for them when trying to fix the errors or include the omissions at a later date. There is no magic bullet for fixing technical debt, so I won't try to provide one here, but at a later date I will be posting about the value of documentation, and hopefully that will give you some ideas about how to persuade people of the importance of getting your documentation correct, consistent and complete.
That aside, don't be afraid to talk in terms of technical debt if you need to persuade your Product Owner to prioritise tasks that will fix these problems. The more that your documentation issues are seen as being similar in scope and type to the software issues, the more likely you are to be supported when you ask for a higher priority to fix your technical debt. It's important to frame requests in language that your development-oriented team mates can understand, and most developers understand both the importance of minimising technical debt, and the frustration that having it causes.
