Implementing Agile is a bold step ahead for most software development teams. Some just want to improve their existing processes, others feel they need a complete overhaul of processes and culture in order to be able to keep pace with the accelerating market environment. There are various approaches to implementing Agile (and scaled Agile in the case of large enterprises), and while it is by definition a less structured method than traditional models, there are still certain techniques and tools that can help your teams cover the practicalities of the cultural transition that Agile is all about.
Scrum and Kanban are perhaps the most widely known and used terms in the context of Agile software development. While most professionals have a general understanding of what they mean, some of those who don’t use these methods every day (or are just thinking about getting started with them) may find it difficult to make informed decisions about which one to use, and how to implement them. This article covers the basics of both methods.
As a method that has its roots in Lean and Just-In-time manufacturing, Kanban was originally devised as an inventory control system in Japan. It has since evolved into a tool that helps promote the improvement of production systems in various industries.
Kanban can be simply summarized and defined as a visual process management system. It’s not a process framework, but rather a tool that helps introduce the idea of incremental improvement.
Essentially, Kanban helps visualize, manage, and monitor workflows in software development, thus enabling the better management of resources. The basis of Kanban is a virtual or physical cardboard, the columns of which represent certain stages of work. Cards (imagine them like post-it notes) represent pieces of work as they pass through the various stages of the workflow. In a software development environment, columns may represent the following categories: to do, in progress, to be verified, complete. That said, Kanban boards can be simply customized for your own work environment. Further horizontal rows (swimlanes) may be added to provide more granularity and thus help the filtering and monitoring of work items (for instance, filtering by assigned teams or team members, therefore enabling commitment tracking).
Essentially, the main benefit of using Kanban is that it helps spot and remove bottlenecks, and manage capacity. By setting Work In Progress (WIP) limits on each column, you can make sure that your teams are always tasked to capacity – in other words, that they have enough work, but are not overwhelmed with tasks. With meetings held in front of the board, you can easily analyze weak spots in the process, and discuss which stages of the workflow operate fine, and which stages could benefit from some improvement. Overall, Kanban helps resource planning, ensures transparency, and lets your teams focus on their work to create better quality products faster.
Scrum, on the other hand, is a well-defined process framework that can also be used in a scaled environment. Scrum “prescribes” the use of short fixed-length iterations referred to as sprints in Scrum terminology. These sprints are the basic units of work for the cross-functional and self-organizing teams that Scrum advises its users to set up.
It is the use of these cross-functional and self-organizing teams that enables Scrum to be Agile, to be really responsive to change. In a Scrum environment, there is no complete, detailed, comprehensive explanation of what needs to be done. Instead, teams are encouraged to devise their own ways of going about solving a problem. Since teams have members from various disciplines, the number of handovers is reduced. If a problem arises (for instance because the customer has changed their mind on what exactly they want the software to be able to do), members can quickly discuss in person the details of the change, and come up with a way to best solve the problem.
A prioritized product backlog is used to collect the requirements in the form of user stories. The sprint backlog draws upon the product backlog, and is set up during the sprint planning meeting.
Pro tip: For Agile insights & best practices, sign up for our Agile Training Course!
Scrum teams are supported by the appointed Scrum Master and Product Owner. Scrum Masters can be thought of as “coaches”, facilitating the team’s work, while Product Owners represent the goal-focused point of view – that of the customer or end user. Iteration planning and sprint review meetings, as well as daily standup meetings help the team stay focused and aligned to goals. Retrospective meetings enable them to incorporate customer feedback in the process of development after each iteration.
Scrum and/or Kanban?
It may not be obvious at first for those not familiar with these two techniques, but while Scrum and Kanban are different techniques sharing the same fundamental goals and values, they don’t rule out each other. In fact, lots of teams choose to combine both in their development efforts, leading to a method referred to as Scrumban.
Related blog post: Scrum + Kanban = Scrumban
Generally speaking, if your teams have their working processes that work just fine but could use some optimization, Kanban is the appropriate choice, as it lets them gradually improve all their tried and tested processes. On the other hand, if the development team seems stuck in a ditch and a fundamental change of processes seems inevitable, you should probably turn to Scrum to enhance efficiency.
To learn more about why and how to use Scrum and Kanban, and practical advice on implementing both methods in your software development, watch our webinar recording from Aug 2016 below. Have tooling questions? Contact Intland Software, or start your free trial of codeBeamer ALM right away!