In today's world, where the budgets are shrinking and 'transformation' is the buzzword, higher efficiencies are demanded from every business. The same is true for technical communications. This is causing a major shift in the way we do our work. There are three key stakeholders who are essentially forcing this shift:

• Business/Senior Management: Business is always demanding everything better, faster and cheaper
• Peers: Collaboration is becoming ever more important in organizations
• End Users: They need easy access to the content on the device of their choice in the language they feel comfortable in

Content professionals are responding to these shifts by embracing newer technologies, better collaborative platforms, and Omni-channel publishing. The part that often gets overlooked is the process.

The manufacturing world started embracing LEAN in the mid-1900s and the adoption of an agile approach to working is increasing by the minute in the HighTech world. All these process innovations are centered around reducing waste, iterating quickly and better, faster and cheaper ways to turn things around.Let's try to understand how agile applies to technical communications in its most simplistic form.In agile methods, instead of building the whole product, you build the smallest possible useful part and give it to users, who tell you what is right and what is wrong. Agile development is an evolutionary conversation in which incremental steps of two to four weeks lead to feedback that allows requirements to be tested and adjusted. In addition, some functionality is available much sooner.

Eric Ries, author of The Lean Startup, calls this a Minimum Viable Product. At the core of it, there's a simple feedback loop i.e. the Build > measure > Learn cycle.

A technical communications analogy to this approach is creating Minimum Viable Content with a special emphasis on 'Viable". The core idea here is to maximise customer value while minimising waste. While doing this, the viability of content has to be maintained at all stages.

The first step is figuring out the problem that needs to be solved and then developing minimum viable content to solve that problem. A good start can be getting answers to some basic questions:

• Does anyone really read this section of the document?
• How often do you refer to the documentation to perform tasks?
• Are there any tasks for which you always refer to the documentation?
• Is the documentation sufficient to perform the job?
• Which tasks require the most in-depth information?
• What is the most frustrating experience with the documentation?
• Is this section redundant? Can I just refer to another document or another part of this document that already states the same information?

Answering these questions should help in setting the right scope and to phase the development of content.The second step is about developing the content in phases. Let's understand this part with an example.

 Suppose, the objective is to take a person from point A to point B with minimum effort. A traditional approach would be:

1. Build a wheel
2. Make two wheels and connect them with an axle
3. Build the body of the car
4. Assemble everything to make a fully fledged car

Though the end product is looking good, it will only be usable after the last stage. Users will have to wait longer and matters become worse if requirements change mid-way. Change management is difficult as the entire design and structure is decided in the beginning.

 The second approach is all about building Minimum Viable Content.Steps here will be:

1. Getting a small pair of wheels and using these to create a skateboard
2. Provide steering capabilities so it becomes a scooter
3. Improve it further into a bicycle and then add an engine
4. Eventually transform it into a fully fledged car

The advantage of this approach is that the end customer is able to use the product right from the first stage. The experience might not be excellent in the initial stages, but it will solve the purpose. There is better scope of introducing changes at every stage. Internal and external stakeholders are able to see the progress throughout and have their say in the development. And last but not least, only the right amount of features get added as it is driven by rigorous feedback at every stage.Quality also increases in agile processes because using a working system exposes inconsistencies right away, instead of leaving them to a final phase.

The last part of the puzzle is how you go about implementing it. Where to start and how to proceed?And the answer is quite simple: Start small and act now.

• Start identifying the low hanging fruits and implement an agile process for producing them
• Select the tools that will allow for faster iterations and review cycles
• Enable Subject Matter Experts to collaborate in early stages of the project
• Measure your performance frequently to realise your end goals
• Engage your end users early to get better feedback

All good things take time to yield results. There's always an inertia of change that will keep dragging you to the state of rest, but consistency in efforts and a will to affect a change can do all the magic.