Mr Agile cooperating with Ms minimalism...

Are you planning to join an "Agile" team of developers? Any idea about the challenges when dealing with "Sprint", "User stories", "Scrum" ? 
Our colleague Paul Coinaud -experienced "agile" technical author- agreed to share his know-how with us.

Let me tell you a (user) story...

Content management professionals’ daily activities are often constrained by the rythm imposed by engineers. This is particularly true when working with software developers. 

Technical writers are "fed" with new features and the flow of delivery is not always very regular, especially when working with several development teams simultaneously. If several projects are released at the same time, you will clearly need to deal with a peak of work. This can also be variable due to the fact that some features require a lot of content to be created, while others require none.

Since the arrival of Agile in Development teams, in particular the Scrum methodology, the rythm is much more regular as the product functionalities are delivered drop by drop, following what we call sprints.

SPRINT?... something for technical writers?

Here is how a sprint is sequenced. The Product Owner makes a list of User Stories (basically features) and prioritizes them in a backlog. A sprint planning allows dev teams to evaluate and implement the selected stories depending on their working capacity during the next Sprint (for example 3 weeks of sprint). So a set of stories is chosen and the devs will focus their work on these particular tasks.

Every day, the devs meet in front of the sprint whiteboard for a stand up meeting called

Scrum – whence the name, to see the progression and raise any potential issue. The Technical Writers can be part of the Scrum to show the team their progression or to raise any issue related to the product or the content.
   
At the end of the sprint, the feature is normally shippable and the related technical documentation should also be ready at this stage. This means the tech writers really work hand in hand with the dev team and their work needs to be synchronized as much as possible to ship a product with a decent documentation on time.

So as the sprint goes, the documentation must follow the progression. 
This gives the techwriters a well-defined working environment, with concrete tasks to perform and clear deadlines.

So let's say it, a little bit of pressure, but we all like to work under pressure, right?

SPRINT and minimalism?

Of course the Minimalist approach is an evidence here. When creating content with short deadlines, you need to focus on two things:

-    As soon as possible during the sprint, tech writers need to work with the devs to make sure the quality of the User Interface is good enough: improve the error messages, correct

mistakes in the labels (geeks love typos!) and if possible, improve the ergonomics as well. A structured product with clear error messages is reducing the probability for the user to require assistance. Plus, it will also be easier and faster to create content around this.

-    Create the information people really need:

• Focus on task oriented content, procedures that will help users accomplish their tasks. 
• Don’t forget to respect the users' level of expertise    
• If you feel like a beginner will need more contextual information before going on with tasks, add a little bit of conceptual information here. A drop.

   
Not only Minimalism and Agile principles are compatible, but if you need to create technical content, it will definitely help you focus on what matters for the end users: task-oriented content, quality user interfaces and helpful error messages with an easy access to the related help topics. 

All this combined with regular feature deliveries is the key to content management success in a software company!