Project Management

Documentation Development in Agile Development Models

In the previous post, we discussed about the integration of Documentation Development Life Cycle (DDLC) with the Waterfall Model of Systems Development. Now that the software engineering is evolving to bring in more speed, efficiency, and tendency to provide quicker insights into the final outcomes, there are newer methodologies gaining popularity. Agile Development is one such approach that talks about having increments of working software developed in some defined time periods to give more clarity and garner confidence of developers and customers alike.

With the change in perspective, documentation development needs to change suit too. Let’s see how does the technical and user documentation get affected while progressing in an Agile fashion. To understand the change solicited by the Agile Development process, let us understand what it demands.

There are many Agile Development models such as Scrum, Extreme Programming, Agile Modeling and so on. For this post, I would consider Scrum model to explain Agile Development process.

The essence of Agile Development lies in more emphasis on collaboration, communication, incremental tangible outcomes, and active customer participation. However, it doesn’t completely ignore the importance and role of processes, documentation, and extensive planning. It puts more focus on what needs to be built rather than aggressively tracking how it is being built. Agile Development is all about being receptive to change and adapting quickly. It also puts more responsibility on team members to communicate, collaborate, give ideas, identify risks, propose solutions, set goals, prioritize tasks, and track the status for one’s work products.

To be precise, the Agile Development models split the main project objective or goal into small and smaller increments that would be developed over a number of time frames such as a week to a month, during the estimated project duration. For every defined cycle, also called a Sprint, each member has to identify his work product or software increment that is complete in a way and can be used.The tasks are identified in a very interesting manner by depicting them as “user stories” wherein a user should be able to use the work product to accomplish something.

Communication and collaboration take the center stage. The team meets before the start of every sprint to plan for it and then once again after they finish the sprint—to review the progress, challenges, risks, identify the lessons learned and the best practices for future. But that’s not all they have for communication and collaboration. They meet on a daily basis in a very short meeting that gives a chance to share about the progress, bottlenecks, and to plan when and where they can get help.

Transparency is the main keyword. All Agile Developments models ensure that all the team members know what the other person is doing. It helps in proper coordination and better planning.

So, the take away for the documentation engineers is:

The technical writers can see the bigger picture right through the beginning as they are included in the sprint planning meetings.

The technical writers get to interact with all team members or any specific member, who could help with the required information. This eases the requirement understanding and requirement gathering challenges.

At every change initiation, they get a chance to discuss the impact on documentation and plan for it in time.

The most important aspect for technical writers is time management and planning the activities that aren’t dependent on work product in any sprint. Some examples of such activities could be preparing templates or stylesheets, and so on. They have to ensure that they schedule such activities either in early sprints where there is more of analysis and design underway or whenever they finish their work product sooner in a sprint.

As for the Documentation Development Life Cycle (DDLC), it shrinks to fit in every single sprint and follows an iterative and incremental approach.

Overall, working in an Agile Development model gives more comfort, support, and visibility to the technical writers and they don’t seem to work out of an island.