Planning for AGILE

Agile has become a popular and widely practised method of software development that it is here to stay. Since agile development is so different from traditional software development methodologies, technical communicators need to adapt to keep up with the pace and style of agile development.

HOW DOES IT WORK?

A lot has been written about agile, so I will keep it simple. It is a method of development where a small group of people work collaboratively to achieve set targets in a set span of time; generally a 3-4 week sprint or iteration. The most widely used agile method is the SCRUM method.

Shorter iterations are better. If the cycles are longer than four weeks, then old habits of working with the waterfall model will start to creep in.

The agile team is a self-organizing, cross-functional unit that works closely, meets often, and does not follow any role-hierarchy – the Scrum Master’s role is just to coordinate meetings and remove hurdles if and when team members report them.

A scrum team typically consists of developers, testers, and a technical writer or two. The maximum size of the team is generally 5-10 people. Any more than this, and agile doesn’t give the desired results. This is because it does not follow any pre-determined process, and does not rely on documentation (internal specifications documents); so it becomes rather difficult to keep too many people on the same page.

Features, broken into achievable units called user stories, are picked up by the team to work on, based on the time each member has on hand. Each of these user stories is developed, tested, documented, and delivered in a set time (sprint).

PLANNING FOR AGILE

The key difference between planning for an agile project and planning for a traditional project is that agile project planning is a collaborative activity. The whole team participates in planning, not just the project manager. Each member of the team, including the writer, is involved, and provides inputs for the master plan of the project. And each of these members is responsible for planning their respective tasks once the high level plan is in place.

With no mandatory internal documentation and no processes, agile can get very chaotic for a writer if not planned and tracked well. Here is how you can induce some semblance of order into the proceedings:

• Shorter iterations are better. If the cycles are longer than four weeks then old habits of working with the waterfall model will start to creep in.
• Always look at the requirements (the user story is a good starting point), and talk to the feature owners and developers to understand the feature.
• Run through all the tasks involved and make a rough estimate of how long it will take for you to write the feature.
• Check dependencies. Does it need to refer to another document? Does it require knowledge of another feature? Add more time to your estimate if it has dependencies.
• Include details of what you will deliver at the end of an iteration (for example, a basic draft, or an intermediate draft with SME comments incorporated). This makes it easier to track. Also, plan when in the iteration you will be able to share a draft with the engineering team.
• If you are going to be on leave, build that into the plan and mention the dates.
• Check how much time you can devote to the project. In a utopian scenario, a writer will work in just one scrum at a time, but that is as far from reality as Utopia is from your current abode. Prioritize activities in your various scrums to arrive at a workable plan. It could be 2-3 hours every day or two days in a week, depending on what works for you and the team.
• Always keep some buffer time to accommodate last minute changes when you draw up the estimate*.
• Discuss the estimate with the team and arrive at a consensus: should documentation be a separate user story? Or a task/child story within a development user story?
• Explain to the team that you will need their help and support because documentation is an essential piece of the user story puzzle – the feature is not considered complete till documentation is delivered.
• Make sure that your suggestions and estimated times are present in the master plan.

If you keep these pointers in mind, agile can be one of the best methods you can work with. It is interesting, challenging, and keeps you on your toes.

Do remember that even though you have planned well, agile is agile; you should expect changes. Sometimes, features will change course in the middle of a sprint. Keep checking if you can accommodate the changes. If not, suggest that the changes be another user story to be taken up in a subsequent sprint.

The next installment in this series will talk about requirements gathering in an agile environment.

*The engineering team may create small specifications documents for their reference; these might become available to you sometime during the sprint. The testing team’s inputs, which typically come towards the end, might also lead to changes in functionality. Plus, you will probably get the first look of the UI towards the middle of the sprint. Considering that you have already been working on the draft, these events obviously require you to make changes to the documentation. Also, technical teams sometimes take the ‘known defect’ route to beat time. In other words, they may ask you to include a few notes or caveats, because there is no time to fix the issues in the build.

Manjusha Nair is a content specialist working with Infosys, Bangalore. She is passionate about innovation and sharing knowledge. In her spare time, Manjusha likes to write poetry and fiction.