Agile practices are often thought of as silver bullets for wrong estimates, bugs, tasks overdue, global warming and other kinds of problems in software development. It is often compared to waterfall methodology, which is a more linear approach to developing software. Let’s get into the detail of these concepts and see what they mean in practice.
Waterfall approach
This is the traditional approach. In a true waterfall project, each stage of software development should be finished before the next one will begin. Stages are typical for all approaches — gathering requirements, design, actual coding, testing, and bug fixing and final delivery. In a typical waterfall project, all requirements are agreed on in the very beginning of the project and are not subject to change. It makes planning and tracking progress much easier since you know the full scope of work in advance.
But requirements are also one of the primary headaches of the waterfall approach. Gathering and describing requirements is one of the most complicated and underestimated parts of software development in my opinion. It’s easy for a customer to get overwhelmed by the amount of information that has to be processed and miss important details. By the time the final product is delivered requirements often change because it’s hard to envision finished product until it’s almost done. Unfortunately, applying changes at later stages of waterfall project is expensive and requires significant effort.
Agile approach
The term agile (lowercase) was popularised in the context of software development by the Agile Manifesto back in 2001. It’s a relatively new set of principles compared to the waterfall, but old enough for most software development teams to know it and use it. The agile development process is much more flexible and encourages responding to change over following the pre-defined plan, as well as valuing collaboration and interactions over documentation and negotiation.
Agile approach adds very little overhead but requires developers to be much more independent and self-driven. It also depends on constant communication and feedback between team members and stakeholders (managers, customers, etc.) It encourages iterative, incremental approach to software development that allows minimizing the amount of upfront planning, requirement management, and design. It is assumed that multiple iterations are required to release a finished product, but every iteration is supposed to be a working product that can be tested by the end users.
Kanban boards
Kanban translates as a signboard from Japanese. It’s a scheduling system developed by Toyota to improve manufacturing efficiency in the 1940s. Kanban focuses on the status of tasks or cards as they move through standardized project stages so that it’s easy to track progress. Whenever a card stays at a particular stage for too long, it’s an indicator of a show-stopping bottleneck that has to be addressed. Such visual representation is especially useful in long-term projects when the job is never done but completing each task is essential.
Kanban is the most straightforward and most useful project management tool that you can implement even offline. Just draw few columns and start adding post-it notes to each one of them and your Kanban board is ready. You can use it to track, navigate and visualize your team’s workflow. You can create your columns, stacks or swimlanes taking the basic concept further. Just keep your board organized and make sure to move cards along as the work progresses or your board quickly becomes irrelevant to the project status. There are also tons of Kanban apps out there, the most popular one is probably Trello. It is free to use and has plenty of example boards so go ahead and check it out if you didn’t already.
Scrum framework
Scrum is an agile framework for managing software projects. Think of it as a particular implementation of agile principles. It has stringent rules described in the Scrum Guide written by Ken Schwaber and Jeff Sutherland, the originators of Scrum. It is designed for small teams and requires work to be broken down into items that can be completed within timeboxed iterations or sprints. It also requires the team to hold daily meetings or standups to track progress and re-plan.
Scrum introduces the new role to the team — a scrum master. This role is different from the project manager or product owner because all scrum master manages is the scrum process itself. He is meant to act as a buffer between the team and all external forces. Scrum guide states that scrum master helps the team to be self-organized and cross-functional while working with the product owner and key stakeholders to maintain product backlog so that only needed work is done and team continually makes progress.
Should you use Scrum, Kanban, Agile or Waterfall?
As usual, it depends on your project. Waterfall works well for small projects where requirements are easily defined and are not going to change. Agile is just a general principle any software project should embrace these days to be efficient and flexible, but it doesn’t give you a process to follow, just a set of principles.
Scrum is really helpful for teams that don’t have an experienced project manager. Use it if you’re new to agile project management but be ready to abandon it once you don’t need it anymore. It gives you a set of rules that you can use from day one to track progress and make decisions in an agile way. But Scrum is making a lot of assumptions that will make senior developers want to leave your team. It is designed to manage weaker engineers and disempowers the better ones so use it carefully. It also contradicts agile manifesto and ignores the fact that software development is all about new tasks that were never done before and expects perfect estimations.
Kanban is just a visualization tool that will work with any project, especially with an agile one. You can’t stop using it once you start and it only gets better over time. Experiment with using multiple boards to visualize different levels or different slices of your project. For example, you can have a board for individual tasks assigned to developers, and you can have another one for high-level feature prioritization. Tools like Trello can give your Kanban boards even more power by providing integrations and adding slightly different views. For example, Trello has calendar power-up that will show you your cards on a calendar if you added proper dates to them
Feel free to experiment and share what processes and tools work for you!
