Once you are granted a virtuous honor to hold responsibility for documentation maintenance in the Scrum team, you must learn to be as flexible as a rubber band and have your time management and communication skills always sharpened. In other words, you have no right to lose your vigilance. Because to assure that project documentation is up to date, you have to constantly keep a thorough watch over the dynamic development processes in your team in order not to miss a thing.
Do you consider the words above rather rough and pushy? Well, if yes – then the role of an Information Developer in Scrum is certainly not for you! And here’s why…
Unless it is appropriately managed and documented from the very beginning, the back-end side of a complex project is usually a mess. If the ongoing web solution is being developed and maintained, it usually comprises a number of various simultaneous streams of tasks that are intensively being resolved and tested during the sprint.
Once the day of the release comes – all of those streams must be successfully integrated, compiled in a build, and then pushed to the production environment with the hopes and, in a best-case scenario, a slight bit of confidence that it will work completely as expected.
Normally, as sprint progresses, you, as a person responsible for the project documentation, besides your planned tasks for the sprint, need to document and keep up to date piles of other details: whether those are changes to the .NET solution, database structural alterations, or new API methods added. And just because 50 % of information about dynamic modifications made by developers can only be collected from both planned and random meetings and dialogs between parties involved, you simply must keep an ear out and your eyes peeled ALL THE TIME.
So, below are a few tips, which actually do the trick, for an Information Developer who’s been thrown into a technically wild, extremely demanding, and thirsty for information Scrum environment.
Get invited to all project-related meetings, whether this is a discussion of the development plan for the upcoming solution between Product Owners and Project Manager, or an estimation session including technical .NET and database tasks among developers. In the first case, based on what has been outlined, you may as well compile your own documentation plan and discuss with both parties the scope of the required documentation on the spot.
By attending the synchro-meetings with developers, you are likely to stumble upon crucial details that affect the core logic that you, however, failed to be informed of earlier for some reason.
Regarding all Scrum procedural meetings, such as sprint planning or backlog refinement – this goes without saying: you should be an attendee #1. Documentation stories can be spontaneously created, planned, discussed, and estimated just like all other development-related stories.
Involvement in communication
Make sure your Project Manager includes you in the most important, in terms of solution decisions, mailing lists on the project. The more information goes through you, the more chances there are for you to accurately plan documentation tasks, provide proper description for each of your tasks in the backlog, and maintain current documents.
Stay tuned. Very often, valuable information may be communicated heedlessly through Skype conversations. Learn how to filter out truly relevant information from all other verbal fun in your team chat. This super-power will of course be revealed with time, but setting some trigger keywords in Skype Notification Settings might help.
Establish a habit from time to time to look through descriptions and statuses of the tasks in JIRA that developers in your team are in progress with. Identify the right time when the stage should be yours: once the developer is done with coding, perhaps, it’s high time you approached him and finally disposed of that piece of documentation business that’s been pending throughout the sprint?
Documentation source navigation
Navigate easily through your documentation and make it painless to access and use for each team member. After all, this is one of your primary duties, isn’t it? Consider your performance a success if your developers can effortlessly navigate to the needed topic in no time.
Project Manager is a friend
Despite the fact that you may actually be friends with your Project Manager, do not hesitate to ask him diverse business- and solution-related questions. Be interested. Get involved. Show that you actually care about the welfare of your project. Remember: your personal success on a project means nothing if the overall project results are unsatisfactory!
All in all, before you get scared of giving it a try in a Scrum team, you should know that eventually you get used to the way things are done and resolved and may very well enjoy the process. In the long run, you’ll be able to adjust it according to your personal needs and preferences, and sometimes even put your headset on to listen to some background music for a change.
Here’s what: the more you practice, the closer you get to mastering the methodology and delivering the best results in the most productive way.