It seems like virtually every software company is starting to adopt an agile approach to product and project management and development, if they haven’t done so already.
An agile approach is an iterative approach to building and improving a product. Instead of closing yourself off and working for months on a big new release, you incrementally improve your product – constantly changing and adapting your plan to the ever changing market.
An agile mindset leads to increased cooperation between teams, enables organizations to react to any feedback they receive, and adapt to any market changes that occur. This results in a much better product, and fewer wasted resources.
While the key to becoming agile is simply to embrace the approach and what it stands for, there are a number of methodologies that you can adopt to help you.
Two of the most popular methodologies are Kanban and Scrum. Both are similar, but there are some differences between them, and each has its own list of pros and cons.
In this article, I’ll attempt to explain what Kanban and Scrum are, how to adopt them in your own organization, and how to decide which is the best option for your team and project management software.
The aim of Kanban is to help your team work together efficiently, ensuring everyone knows what needs to be done. It enables product teams to continuously build and release product improvements and features without becoming overwhelmed and encumbered with long to-do lists.
Kanban was actually first created and used by Toyota in the late 1940s, where factory workers would pass a card (a “Kanban”) from one person to the next, providing a clear visual way of identifying which resources were needed when.
Other companies, from a wide range of industries, started emulating this method, and to great success.
It wasn’t until software companies decided to get in on the act that the true power of Kanban came to light. Lean companies, with minimal resources, could employ Kanban at virtually no cost.
While factories could potentially incur significant costs if they were to adopt Kanban, software companies could use virtual boards and cards, avoiding those costs.
(Photo by Daniele Riggi on Unsplash)
Kanban has two key elements: the board and the cards. While the board can be physical, software teams tend to prefer a virtual board – as this is more easily accessed from multiple locations and makes collaboration more efficient.
Generally, the board can be split into three sections. These are “To-Do,” “In Progress,” and “Done.” These sections can be mapped out to fit in with your team’s workflow. You might, for example, split the board into “Building,” “Reviewing,” and “Done.”
The other key element is the cards. Each card should represent a specific task or project. There are some crucial pieces of information that each card requires. These are:
You may also wish to include further details, such as screenshots, technical details, or even relevant customer feedback.
The idea is that everyone on your team knows what’s being done and who’s doing it at any given time. These cards are then moved along the board from section to section as the task progresses.
Combined, the board and the cards provide a clear way of visualizing what’s being done and what needs to be done in future, ensuring every team member is on the same wavelength.
Scrum was first created in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in their article for the Harvard Business Review. They likened their approach to the game of rugby, from which the name Scrum was taken. Teams pass tasks between members, moving forward as a unit, much like a rugby team passes the ball among themselves.
The point of Scrum is that it provides a holistic methodology, whereby the whole development or product team work together to achieve a common goal. Teams using Scrum recognize that customer requirements can change quickly. Those shifting customer requirements, coupled with unexpected issues that can, and will, arise, mean you have to be able to adapt and change.
Scrum teams employ an empirical approach based on evidence and focus on how to build and deliver product improvements and new features as quickly as possible. They should be agile enough to adapt to constantly changing markets and customer requirements.
Scrum consists of sprints – one after the other each ending in a milestone. There are four main stages to a sprint.
The first step is the sprint planning stage, where everyone involved sits down and decides what they’re going to build in the upcoming sprint.
Second, you have the daily stand-ups. These are meetings, often no longer than 15 minutes to ensure everyone is on the same page. These happen throughout the sprint.
Third, after the sprint has finished, you have the sprint demo. This is a longer meeting where the team shows off everything it has built and shipped.
Fourth, you have the retrospective, where everyone involved in the sprint reviews what went well, what could be improved, and discusses how to make the next sprint even better.
This is a process that ensures everyone is aligned and knows what they should be working on at any given time.
Kanban and Scrum both have their pros and cons. So, perhaps, “Which is better?” is the wrong question.
Really, you should be asking, “Which suits my team more?” (Making sure that you can successfully adopt whichever method you choose is far more important than deciding which is better.)
With that in mind, let’s compare the two processes in terms of how they work.
Kanban is a continuous process, meaning that tasks are constantly being added, worked on, and completed. As soon as you finish one task, you move on to the next one.
Scrum, however, is iterative. Each sprint is a self-contained project that eventually ends. Before moving on to the following sprint, you plan for the next one.
Your choice here really depends on how your team like to work. If it prefers to just get on with things and consistently roll out new features or improvements, then Kanban will be more effective.
If, however, your team likes to plan ahead of time and has a clear idea of what is needed to be achieved, then Scrum will be the better choice.
Kanban doesn’t introduce any particular roles to your team. Every team member plays their own part by working on a task. Generally, of course, you’ll have a manager who delegates the tasks out, but, otherwise, the team can be fairly fluid.
Scrum is different. You need to establish several roles. You need a product owner, who champions the product and manages the backlog. You need a Scrum master, who owns the Scrum process and coaches the rest of the team on it. Finally, you have the development team, who do the building.
If you prefer a fluid approach, where you won’t have to restructure your team or establish new roles, then Kanban is perfect, as you can start using it right away with your existing team.
If you’re building a team from scratch, then Scrum could be a wise choice, as you’ll be able to structure your team with the required roles and start using Scrum from the outset.
(Photo by Brendan Church on Unsplash)
Due to its continuous nature, Kanban enables teams to constantly pivot and change direction in light of any new feedback or strategy changes.
Scrum, on the other hand, is based on focusing on a sprint and following it through to the end, no matter what. Any changes are prohibited, so the only time a team can pivot or alter its direction is in-between sprints.
If you’re serious about managing product feedback and listening to your users, then Kanban is ideal, as you can change direction to constantly align yourself with your users’ priorities.
If you’d rather focus on one thing at a time and simply work to your own strategy, then Scrum will be a better fit.
Both Kanban and Scrum offer slightly different ways of achieving the same thing. Both are based on using an agile methodology to make constant improvements to your product.
Neither one is objectively better than the other. Choosing which one is right for you really comes down to how your team is structured, how fluid and adaptable you want to be, and which feels like the best fit.
Of course, an alternative would be to take elements from each and form your own hybrid agile methodology that is perfectly suited to how you want to work.
Whatever you choose, the key thing to remember is that being agile leads to better cooperation, and, to a more reactive approach, enabling you to build the best possible product.
Ready to become a better project manager? Uncover the best project management tips in 2019 to help you crush your goals.
Virtual communities have blossomed in recent years.
by Jean Hamon
The work from home lifestyle is here to stay.
by Lauren Pope
