By Rivi Aspler
Successful product managers rely on many things to bring the best product to their customers. Whether it’s the right timing, enough R&D power, a good vision, cooperative customers or even luck. Many factors are calculated in an unknown formula to create a winning product.
What about the Agile methodology that the organization uses? Is it an issue at all for you as a product manager? I would claim, that not only it is an issue, but an important key success factor that you should consider and adjust to best fit your needs.
How Scrum and Kanban are Different?
Scrum and Kanban are two terms that are often used interchangeably. In reality, there are significant differences between these two methodologies. Understanding the differences is key to choosing the path that will work best for your needs. Here are the main differences between the two. The differences relate to time-boxes, cadences and daily flow of the product/project advancement.
Now, let’s start applying that to Product Management.
How Important are deadlines?
Have you ever been in a meeting where a deadline has been set but you knew going out of that meeting that the sky wouldn’t fall if the group didn’t meet that deadline? We’ve all seen both types of deadlines: the set in stone, date cannot move deadline and the somewhat loose, would be nice to meet type of deadline.
Scrum processes place heavy emphasis on schedules. The product manager (or owner, depending on the organization size) provides the scrum team with a prioritized list of story points that need to be completed to deliver a ‘shippable’ product. Flow wise, after the user stories have been detailed, the development manager will ask the team how many of the points they can complete within one sprint. Anything outside the scope they commit to must wait for subsequent sprints. When the sprint starts, the product manager is obligated not to change the scope of the sprint.
When it comes to scrum, the development manager is responsible, among other things, to understand the capabilities of his team members, so that their estimates will improve and be optimized as time goes on. This iterative process is designed to allow for accurate estimations of work flow and effective management of multiple projects.
On a Kanban team, on the other hand, there are no required time boxes or iterations. While the Kanban method is iterative in nature, the team is expected to do the best they can, without committing to a certain amount of user stories. The development occurs in an evolutionary fashion as work is continually completed.
You can now see where all of this is going….
As a product manager, if deadlines are clear and cannot be moved. Scrum is the right path for you. If it’s all about the evolution of the product, with no harsh milestones, Kanban will probably serve you better.
The following questions can assist you in understanding how rigid your timeline is:
- Will new customers sign a contract by a certain date, only if certain features are in the product offering?
- Will existing customers renew a license by a certain date, only with a promised product scope?
- Are you sponsoring an event at a pre-defined date and need to show a certain feature by then?
- Do you know for a fact that your competitors are about to release key differentiating features by a certain date?
If you have answered YES to any of these questions, scrum is the best agile methodology for your team to work by.
How Flexible is your Agile Board?
Scrum and Kanban boards are very different in nature. The key words are rigidness (of scrum) vs. flexibility of the board (in Kanban). Both have their pros and cons. None is perfect. Which method fits your needs better?
Scrum makes sure the user stories that the development team had committed to are completed in each sprint. This means that the scrum team must move items on the Agile board from left to right; from start to end.
To be able to do that, the scrum team will insist on a detailed planning of each sprint, on detailed user stories and on detailed technical designs to accompany every user story. Before every sprint, the sprint pre-panning phase imposes considerable pressure on both sides, the product manager (owner) and the development team. The upside of this process is a semi-factory features-production type of setting. The downside of this process is that it imposes more pressure on all people involved and a time-consuming effort estimation process.
On a Kanban board, developers are required to evolve the product responsibly and excellently. They can work on maximum amount of user stories at the same time (my recommendation is not more than 2 user stories in parallel). Since each column has a limited number of allowed stories and there are no required time boxes (such as sprint length), there is no reason to reset the Kanban board as work progresses. It will continue to flow for as long as the project continues, with new stories that a product manager will add, as needs arise being added as the needs arise.
The up-side of a Kanban path, is usually a more mature product, technically speaking. Developers love Kanban. It allows them to better plan, code and test the features that they are releasing. Developers that are working by Kanban are usually more content with their day-to-day duties. The down-side of a Kanban board, as far as the product manager concerned, is a potentially less feature-rich product.
Bringing it all together
Scrum or Kanban? There is no right or wrong here. Your needs will determine the right methods for you. Your market, type of product, type of customers, cultural setting, and even co-workers preferences, all should be taken into consideration when insisting one method or the other.
Concluding it all, I would like to say that in my experience, a hybrid method works fine as well. This doesn’t go with the theory but works fine in reality. I usually define a 2 weeks scrum-sprint and am more flexible with moving items back and forward on the board, to fit my scrum team’s questions and concerns.
Note that there is an official methodology called Scrumban. Just like it sounds, it’s a mix of Scrum and Kanban.
What are you working with? Scrum? Kanban? Scrumban? Something else? Please tell us why.
Tweet this: Which Agile Methodology Serves You Best? Scrum or Kanban? #prodmgmt #agile https://wp.me/pXBON-4yh
About the Author
Rivi is a product manager with over 15 years of product life-cycle management experience, at enterprise sized companies (SAP), as well as with small to medium-sized companies. Practicing product management for years, Rivi now feels she has amassed thoughts and experiences that are worth sharing.