“Agile” refers to “agile software development,” the approach to development that follows agile principles. But what the heck are “agile principles?” Take a look at the Agile Manifesto and at the 12 principles of agile, which lay the foundations of agile development. From the Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The Manifesto and principles are the result of searching for the best solutions that have evolved over the decades in response to the challenges of software development. Throughout the 70s, 80s, and 90s, different developers and teams all over the world had been experimenting with methods of working and approaches to problem solving, inventing different frameworks and techniques (such as scrum and Extreme Programming). Finally, in February 2001, seventeen developers got together and found the common denominators for all these diverse ideas and experiences. That is how the manifesto was created.
The Scrum Guide defines scrum as: “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
Scrum consists of three roles: Product Owner, Scrum Master, and Development Team; four ceremonies:Planning Meeting, Daily Scrum, Sprint Review, and Sprint Retrospective; and three artifacts: Product Backlog, Sprint Backlog, and Product Increment. It is organized into regular time frames, which we call sprints. Sprints should last between one and four weeks.
The Product Owner is responsible for guiding the project’s direction. As new tasks and features are determined, the Product Owner adds them to the Product Backlog. A sprint starts with a Planning Meeting where the Development Team selects the tasks from the Product Backlog to work on and plans how they will be implemented. That is followed by development, during which the Dev Team uses the Sprint Backlog to track progress and meets for the Daily Scrum in order to synchronize activities and adjust the plan, if needed. The result of development should be a Product Increment, something that can be applied to the product and released immediately. At the end of the sprint, the Product Increment is presented to the Product Owner at the Sprint Review, where the product backlog is augmented if further changes are needed. Afterwards, the whole team attends the Sprint Retrospective (also known as the Pub Meeting) where we talk about the work process and how it can be improved.
Why is scrum so popular, and why does it have an advantage over the traditional waterfall model? Simply put, because it delivers more value to a product and customers. With planning-intensive methods such as waterfall, horror stories abound in which nobody sees anything of the project for months and issue discovery is left until the very end. With scrum, that is not possible.
Scrum is all about the value that is delivered to end users. If you really utilize scrum, you need to deliver something of value every sprint. The value can be measured, and the team is also forced to inspect impediments and adapt, with the goal of delivering more value in the next iteration.
In most software development we are not building a skyscraper; we don’t need to have the whole plan ready before we start, and stick to that plan until the end. We are developing software, and we have the ability to adapt to different situations and to change the product requirements during development. For a long time, many developers saw this as the eighth deadly sin, but from the product perspective it is a huge benefit for optimizing predictability and controlling risk. Scrum is developed around this ability, and its implementation gives a reliable and efficient way of dealing with necessary changes.
Many techniques are used in conjunction with scrum. One method often mentioned at the same time as scrum is kanban, and there is a lot of confusion about what these two things mean in relationship to each other.
When you talk about scrum and kanban, one frequently asked question from the seats in the back might be, “Which is better, scrum or kanban?” And you won’t know how to answer because it’s like comparing apples and oranges, or asking, “Which is better, pancakes or margaritas?” Both are good in my book.
Kanban is a simple method that aims for just-in-time delivery while not overloading the team members. It is similar to scrum in that the goal is to deliver maximum value at the end, but it is much more flexible than scrum. Kanban was not invented by the software development community. In fact, it has its origins in manufacturing processes at Toyota, and it has wide usage in other spheres. There are no strict procedures that you should follow, and no strict way you should implement and use kanban; I’ve read, rather, it’s a set of principles and practices, and you can choose from these practices to suit your needs. But there is one most-often used implementation of kanban in software development that includes the usage of a kanban board, consisting of columns representing stages of work, and tasks.
Columns represent the state of a task in the development process. The simplest example consists of three columns: “To Do,” “In Progress,” and “Done.” So, tasks are added to “To Do,” moved to “In Progress” when development starts, and considered “Done” when moved to the last column. But of course, it could be more complex:
“Backlog” → “Defining Specification” → “Ready for Development” → “Development” → “Code Review” → “Testing” → “Deployed” (→ “No one really uses it” → “Completely Removed”).
The purpose of this board is to visualize the workflow, which is the first key practice in kanban. It could be a simple list of tasks in a Google sheet with different background colors indicating the state of the task, or it can be Gantt charts, diagrams, tables… It could even be a set of buckets in your office, where each one represents the state of the task, and where balls are used as tasks. Just visualize the workflow and provide transparency to the whole process.
Which Should I Use?
In scrum, there are defined roles, while kanban says, “Hells bells, keep your current roles and responsibilities.” Scrum will force you to change your current way of working; kanban lets you start with your existing process. In scrum, a clear schedule for events is prescribed by the framework; in kanban you don’t have events. Yet, they have a lot of similarities: Both are value-centric, team members are respected as “bosses” of the system, and essentially, they have the same mission: To continuously eliminate waste and remove obstacles.
But the question, “What should I use in my particular project and with my particular team?” makes much more sense. Kanban doesn’t require so much of the process and cultural changes, and, in most cases, it will be easier to adopt than scrum. Scrum, on the other hand, offers significantly more structure to guide the process, which can eliminate a great deal of overhead as long as everyone is on the same page.
But the beauty of both is that neither is a strict set of rules. There is nothing stopping you from picking and choosing the best scrum elements for you, such as a daily meeting or review. And there is no reason you cannot incorporate a kanban board into scrum.
The truth is that every project is different, and there is no one-size-fits-all solution. As a project manager and product manager, it is up to you to determine what works best for your team and for your product.