Software development is such a process that differs from other kinds of engineering procedures. It requires the attention of a mobile and flexible team that is willing to respond quickly to changes. This is when Agile methodology steps in.
Agile methodology is a set of routines oriented toward the efficiency improvement of software development specialists.
It is more of a philosophy selecting principles that value adaptability and flexibility – Agile aims to provide better awareness to changing business needs. One can apply various frameworks within Agile project management to develop and deliver a product or a service. Each agile framework highlights a specific approach and focuses on a determined result. A particular Agile approach is chosen depending on the requested outcome. They each have their own set of characteristics and terminology, but at the same time, they share common principles and practices.
Two of the most popular approaches that support the Agile development life cycle are Scrum and Kanban.
What is Scrum?
Scrum stands for delivering high-quality software in a minimum amount of time. It uses iterative timeboxes called sprints. Sprints last four weeks at most and have clear start and finish dates. Throughout the sprint teams:
- create documentation,
- develop scrum software,
- monitor work processes,
- and then improve to ensure future successful projects.
A Scrum team consists of three roles:
- Product Owner is the one that represents the project stakeholders, that person is available throughout the development process to answer questions, review completed work, and prioritize requirements.
- Scrum Master leads the development team making sure that the team has the skills required to finish the project successfully and everything is running smoothly.
- Development Team is a group of specialists who are responsible for doing the work that’s described and prioritized by the Product Owner.
Scrum is created to ensure that teams are working at a constant pace and consistently improving throughout a project, and the work is completed in time. With the Scrum model, team communication is a priority. The team must understand precisely the tasks they are working on and the progress that is being made. That helps the team move toward the goal without stumbling on many barriers along the way. In addition, the scrum master can track the team’s progress and initiate “speed” encouragement when needed with performance schedules.
What is Kanban?
Kanban promotes changing environments, constant iteration, and agile delivery. The Kanban approach also helps you visualize your workflow and locate any current issues. Kanban board is the main tool that helps to visualize the development process. Typically it has three visual columns — To Do, Work in progress, Done. You can insert tasks constantly during the work process when the team needs to adapt to the changing wants of the end-user.
Kanban has six main principles that any team should adhere to when working with it:
- Workflow visualization to help easily identify issues and fix them.
- Limiting WIP (work in progress) to increase productivity by setting task limits.
- Workflow management to optimize the workflow when observing tasks that work best and that don’t.
- Adhere to policies. The team needs to adhere to the agile workflow guidelines so that every member of a team is on the same page and does quality work.
- Feedback loops. Usually expressed in daily meetings where a team assesses the current situation and makes improvements in a work process.
- Continuous and experimental delivery evolution. With constant improvements, the team can speed up the work process and continuously deliver pieces of software to the market.
Scrum vs. Kanban
As you may see, Scrum and Kanban are very alike as they are both subsets of the Agile philosophy. At the same time, they differ in ways that can make you prefer one over the other. Let’s see their distinctions.
Kanban methodologies are constant and more variable when Scrum is based on short and structured sprints.
Scrum is a complex and strict methodology with many rules and a highly specific framework that teams must adhere to. Kanban is a leaner approach with fewer rules and a simpler framework. Both, however, help teams adhere to the core principles of Agile.
Kanban uses an assembly-line approach to move work through a queue. Like Scrum, Kanban has a backlog of prioritized project tasks, but rather than planning work in sprints; team members take the highest-priority task in the backlog that’s ready to be completed. Whereas Scrum processes require high control over what is in scope, Kanban lets you float with the stream.
Neither methodology is better than the other. The right choice for your team depends on your organizational structure, team preferences, and the specifics of your work and project.
Another important thing is that you don’t necessarily have to always adhere to one methodology. In fact, teams that have been working together for a while can easily switch back and forth between the two methodologies to accommodate different types of projects and sets of work.
Agile Approach to Documentation
Agile development methodology was created as an alternative to the documentation-driven development process; it did mean to eradicate internal documentation. It just added more value to working software than on comprehensive documentation because software development is dynamic.
So if you need to create a lot of documentation for the project, nothing in the Agile development methodology inherently prevents you from doing it.
Therefore, the documentation should be as efficient as possible to achieve relevant goals in agile software development projects. Agile documentation is an approach to create compact documents that address the immediate situation.
What is Software Documentation?
Software success is impossible without good documentation practices. It can be challenging to develop a software product from scratch, launch it, and then attract users. So, to keep everyone in sync and make it easier to navigate, the concept of software documentation emerged. Software documentation describes the development, functionality, and/or the use of a software product. Writing effective software documentation is a complicated process, requiring technical writing expertise.
Agile Documentation Types
Agile software development methodology is about the rapid deployment of changes into the software since it advocates adaptive planning, evolutionary development, and continuous integration. It is interesting, though, that agile documentation as a term doesn’t exist. However, it is widely used to imply the active documentation done while the software product is being created using Agile practices. With every project being different, there are different types of documentation that can be maintained by the teams. But two main categories for software documentation are:
- Product documentation
- Process documentation
Examples of possible Agile documentation include tables, diagrams, case studies, etc. Here are some of the documents you might want to create during your project:
- Product vision statement. It’s a description of the core essence of a product. It describes what problems it solves, for whom it is designed, and why. A Product vision gives your team a bigger picture of what they are working on.
- Design review. This is a brief of information concerning the project, for example, technologies, and tools used to build the system.
- Design concept – general information about crucial decisions involved with design and architecture made by the team at all stages of the project.
- Operating and maintenance documentation. This is usually a guide for employees to perform their functions correctly and efficiently.
- Accompanying documents. The training materials specific to support staff, troubleshooting guides, etc.
- System documentation. Provides an overview of the system. It helps to ensure that if the development team leaves, critical information remains.
- User documentation. Includes manuals and support guides for the users. Keep it simple and easy to understand.
Documentation in Scrum Methodology
Without a technical documentation management process, tasks can come from any source spontaneously and be assigned to the development team, with little information or resources allocation. By adapting the Scrum process for managing technical documents, this scenario can be avoided. In addition, managing and tracking projects this way gives each team member greater transparency and responsibility for working with documentation.
The tech documentation managing process includes the following steps:
- Define the upcoming projects (sprint planning). Review the upcoming projects before each sprint. It is worth getting an idea about the work and the priorities set. In order not to be surprised when the work appears two weeks before the results are needed.
- Create a documentation plan for bigger projects. Such a plan contains many details that are needed to stay on top of the project. This is not a waterfall approach or a document outline, but a list of notes about a project, such as who is who, where are the QA test scripts, expected results, planned release dates, key product documents, etc. Such a documentation plan serves as a kind of checkbook for the project.
- Divide the work with documentation into tickets (tasks). Tickets related to the job are generated from the documentation plan. They should outline the main tasks for each project and give an idea of the work needed. The main idea here is to simplify complex tasks by dividing the work into smaller ones.
- Breakdown tickets into two-week sprints. Tickets should be distributed across sprints. Each sprint usually lasts two weeks long. This pace of passing the marks is called speed. Understanding your speed is only possible after a few sprints. Calculation and communication of speed information are important to know if technical writers have everything they need to carry out the work, taking into account the timing of the releases.
- Stakeholders should be aware of the work on documentation to see the progress of their projects. Sprints should not change their assigned values unless the documentation is prioritized. Emergencies and crises should be taken into account. With the Scrum approach to documentation, it is challenging to hold to a sprint plan. Different teams may have immediate needs for quick updates. The Scrum process is important here – it balances the current workload and eliminates excessive and distracting work. You don’t need to go faster than your current speed due to unfinished documentation tasks.
- Issue two-week sprint reports at the end of each sprint. Share the details of what has been accomplished with everyone interested in the work. This usually involves sending updates by email. The reports show completed tickets after a closed sprint and tickets scheduled for the next sprint. The sprint report is one of the most important tasks to complete. It lets people know what a tech writer has been working on.
- Review documents before publishing. It is worth doing a review process to ensure that the documents meet the quality scale. This process shows how the product meets the customers’ needs. It is worth looking at the documentation portion corresponding to completed tickets. Because trying to view too much content at the same time is overwhelming.
Documentation in Kanban Methodology
In Kanban, there is no prescribed documentation of any kind. It is a very lightweight, continuous flow process that is simpler compared to that of Scrum. Each work item in Kanban is processed individually as soon as capacity is available to work on it. Let’s see an example of how this methodology works with documentation.
Imagine you have a large pile of documentation accumulated over time, and you need to structurize it somehow. What will you do?
- You can create a shared Kanban board where you break the documentation into categories to create a navigation system.
- Give general names to the columns that would enable sorting. The Kanban Board should have as few columns as possible, but at the same time, the board should reflect actual workflow.
- Create cards for all the topics you are planning to cover in the documentation.
- You can also flag some cards with different colors to indicate either a topic is missing and needed to be created or present and needed to be removed.
- Then put all the cards into an “unsorted” column. You can ask your team members to drag them where they thought the cards should be organized.
- Agree on the structure and make corresponding modifications.
- From that moment, you can convert information into menus or submenus.
There! Now you have the logical structure with the help of Kanban board card sorting. Your content is set up in a way to give users the information they’re looking for.
In any case, your Kanban board should evolve as you understand your process more and you start making changes to become leaner.
How to Organize the Creation of Documentation in Agile Methodologies More Productively?
You may say that the documentation in Agile is “fluid” and is collaboratively maintained by the whole team. There are a few simple rules:
- Always remember that you’ll have to maintain any document you create later on. If the documentation is light, uncomplicated, and not too detailed, it will be easier to comprehend and update.
- Don’t rush to document if you want to avoid accumulating false and outdated information. Produce documentation when it is needed, not before.
- Gather your documentation in one place. Remember, it should also be accessible to be useful. Store your product documentation in a place where you and your team members can easily find it.
- Collaborate with your team. Maintaining documentation in Agile teams is a collaborative process, and every team member should contribute to the process.
If you want to make all of the above possible, you need flexible and easily accessible software documentation tool.
Conclusion
The Agile methodology gives you the ability to be highly responsive to changes and make improvements while you’re documenting your agile project. As for Scrum and Kanban practices – it is easy to point out the differences between the two, but that’s just at the surface level. While the practices differ, the principles are largely the same. Both frameworks will help you make better products (and documents) with fewer headaches.
Good luck with your technical writing!
ClickHelp Team
Author, host and deliver documentation across platforms and devices
