Documentation for Agile project management and Scrum software development teams.
Since Scrum is a project management framework that aims to minimize costs and maximize business value, project managers must continuously look for ways to improve productivity and efficiency.
Agile and documentation are not two words that are often associated in articles or blog posts. Scrum teams have however to find alternate ways to spread the knowledge among their member. In this article, Viktor Cessan explains how he uses an exercise named History Lines to share knowledge in Agile teams.
As the Agile Manifesto stated that it prefers “working software over comprehensive documentation”, some early Agile adopters jumped to the conclusion that documentation was useless. Thus Scrum software developers should only concentrate in creating working software with code that was the most easier to understand.
Documentation and Agile are two words that are rarely seen together, but documentation is still the most important thing developers continually respond as most affecting their decision making. Frankly caring about documentation shows you care about the developer, whether external or internal. Yet, documentation is constantly pushed to the wayside, aligning that idea with Waterfall and top-down development. How do you then foster a culture that gets your developers excited to create documentation? And as an extension, how do you get your developers excited about pleasing their customers?
One of the major selling points of Scrum to developers is how much less documentation is involved. Developers worked hard to get where they are: a college degree, nights and weekends at home working through books and exercises trying to learn the latest language, and struggling through their first few projects to get something that works into production. They don’t want to come all that way just to spend most of their day in the word processor. They want to code.
During Scrum adoption, people tend to get away from tasks and activities that they don’t like in traditional projects like documentation or writing proper code comments. In this article, a ScrumMaster shares his experience with a “no documentation” approach. He learned the hard way that minimal documentation is better than no documentation in Scrum projects. The team can decide on a case-by-case basis what level of documentation for which components and code logics is needed.
Does the term “documentation” have any place in an agile environment? The goal on agile projects is to keep documentation as simple as possible, relying on roadmaps, overviews and concepts rather than enterprise-focused details. But what happens when using an agile approach on more complex projects? For example, what if the team that writes the software is different from the team that must maintain it? Or what if auditors come calling? In these instances, basic agile documentation based on user stories alone may come up short. This article provides insights into how teams can take an agile approach to documentation in more complex environments.
Scrum Expert Copyright © 2009-2024 Martinig & Associates