Scrum vs Kanban
This is part 5 of a long-form series of setting up your Product Stack’s Project Management correctly.
You can read Part 4 about the setup of the Project Management structure of your Product Stack here.
If you’ve already chosen a specific methodology for the process of building your Products, feel free to skip over to the next part where I discuss how to organize your Scrum or Kanban Project boards to extract the maximum value and track all your Product building efforts.
Which method of Product building to choose between Scrum and Kanban? These buzzwords have been garnering a lot of attention and most teams and organizations I know have switched to some form of Agile development. A lot has already been written about the intricacies of Scrum and Kanban. Without going into too much detail about which one is preferable, I’d leave the decision-making framework for you to decide the best case for yourself. But first, let’s understand what is Agile, and what are these two flavors of Agile methodology that have become the go-to methodologies for building software products.
In part 4, we discussed the different issue types that you will need for all your needs for building your Products or managing your deliverables. Out of all the Issue Types mentioned, you would only need to manage your active development on the following Issue Types -
- Development User Story
- Design User Story
- Task
- Copy Writing
- Usability Testing
- User Research
Some other issue types such as an ‘Initiative’, ‘Feature’, or an ‘Epic’ would be too large to feature in a scrum or kanban board to track progress since these are the exact Issue types that are broken down into implementable pieces in the form of development and design user stories.
Agile Development
Agile development is a product-building methodology that emphasizes continuous development by breaking down large projects or large goals into smaller deliverables and improving on smaller levels.
The Agile approach prescribes that the long time taken to build very large systems is not in the interest of the users for whom they’re meant. These users should rather be given smaller software versions to use and these versions should be continuously improved. Building Products in such a manner eliminates a lot of sunk cost risks as well as results in better iterative feedback from users.
Please note that ‘Agile’ is a set of principles in the form of a manifesto and has implementation guidelines along with it to build your processes upon. There are two most common methodologies in Agile development -
Agile Scrum
Agile Scrum is an implementation mechanism of Agile development that focuses on the creation of smaller teams with specific skill sets that usually try to achieve a deliverable objective in a time-boxed manner. These time-boxed deliverables are what’s called ‘Sprints’ in Scrum.
Over a period of a set decided time (usually 2–3 weeks), one or more sets of ‘Scrum’ teams come up with their requirements (in the form of design ad development user stories) and corresponding deliverables (in the form of epics) for planning this cycle of time of building. Scrums are usually managed by a designated personnel, commonly a Scrum Master or a Product Owner to ensure that the daily activities of a scrum are carried out correctly. A scrum has the following ‘ceremonies’ to conduct as a part of its prescribed best practices -
Scrum Standup
A scrum standup is a daily cadence meeting conducted between the members of a ‘Scrum’ and the scrum master where everyone reports the current status of their deliverable, their roadblocks, and their next action item and priority of the day. This helps bring everyone up to speed with the status of the current sprint and highlights any potential spillovers and roadblocks for the team members. In the modern-day setting, an Associate Product Manager or a Product Manager should act as a Scrum Master of each Scrum.
Please note that you should be conducting your daily standup calls and they should be between the Product Manager, the Engineering Manager, or the Tech lead responsible for the delivery of the sprint.
Sprint
A sprint is a period of time during which your ‘Design’ or ‘Development’ team delivers their assigned action items against an estimated time that they already assigned to those action items.
If you’re operating in an ‘Agile Scrum’ manner, then you should ideally have two different sprints -
Design Sprint
A design sprint is a sprint that delivers the design requirements to be built by the development team over a specified period of time as discussed above. Please note that the design sprint should operate with a head start of a week or two over the development sprint to have enough requirements ready to be given out for development.
Development Sprint
A development sprint is a sprint that delivers the engineering requirements to be built over a specific period of time. A development sprint should operate with a lag on the design sprint.
Sprint Planning
Sprint planning is the process of prioritization of ‘user stories’, and ‘copywriting’ tasks that can be delivered in the designated time period of a sprint. This planning is conducted by a ‘Scrum Master’ and it is conducted on a list of ‘Issues’ that have been estimated with respect to the amount of time it’d take to deliver them. Here, the planning process takes place to ensure that every team member of a Scrum has the right number of issues assigned to them such that they’re meaningfully occupied for the time period.
For Example — Person A has 10 days worth of effort in a 2-week Sprint cycle. It should be ensured that this person gets assigned Issues such that the sum total of the time effort estimated for those issues is between 8–10 days.
You should conduct your sprint planning at least two days prior to the start of your sprint. Usually, sprints start out on Tuesdays or Wednesdays and finish up on Mondays or Tuesdays.
Sprint Retrospective
Sprint Retrospective is a time-specified recurring cadence meeting that’s meant to elicit feedback on the process of development and then iterate on this feedback to correct processes and the method of Agile implementation in Scrums.
Agile Kanban
Agile Kanban is an implementation mechanism of Agile development that focuses on the creation of a continuous never-ending stream of work that keeps flowing between stages. Just like Scrum, Kanban can have multiple teams that work on their respective deliverables.
Kanban works on ‘status’ lines known as swimlanes that list all the issues that have that status.
If you’re operating in the Agile Kanban manner, you should still have two different boards for design and development efforts since the efforts
Work In Progress Limit
Since there’s no time boxing of effort in the case of kanban and there could be as many issues in any status on the kanban board, there’s a concept of Work In Progress Limit which mandates that there can’t be more than a certain number of Issues in any one of the defined swimlanes of statuses of a kanban board.
So, which one between Kanban and Scrum to employ for your use case?
Here’s a basic thumb rule I’ve come up with for deciding —
Organization Structure
In part 4, we discussed two types of organizational structures. In case your organization is divided according to Business Units, then I’d recommend using a Scrum methodology since almost all Business Units might have Product requirements to build for which might need constant prioritization and grooming of your backlog.
In case your organization is divided by Functions, then I’d recommend using a Kanban methodology since it’d mean a constant stream of requirements being provided by each Function which might need building one after the other.
Product Team Structure
If the organization structure that you have operates in smaller PODs for your Product, then I suggest that you assume your smaller PODs to be small Scrums with either the Engineering Manager or the Product Manager assuming the role of the Scrum Master. If you don’t have a POD division or have a unified development team, then I’d suggest doing a kanban would be better.
Product Stack Size
If the size of the stack of your Product is equal to or less than 3 products, then the complexity of management of development efforts across will not be much.
At more than 3 Products, the complexity of managing ‘Initiatives’, ‘Features’, and ‘Epics’ becomes too large and might need you to find a solution that tends towards cutting off the requirements to be built by a certain time and build on them for a time period before picking up the next set. If you have 3 ‘Initiatives’ each, then you’d have a couple of ‘Features’ and a few ‘Epics’ to build. This would mean building 20–30 user stories at the same time. On this level, I’d suggest moving away from Kanban.
Product Planning Horizon
If the planning horizon for your product is about a quarter or more, then you should have a Scrum methodology for building products since it would imply breaking down a lot of Initiatives and features into deliverable Epics, and their consequent user stories. Hence, the need for constant prioritization and prioritization would be required.
Here’s how I’d summarize which methodology to use -
Summary
Here’s how I’d try to summarize to above article.
The larger the complexity of deliverables in your organization, the larger its size, or the more the number of your PODs, you should start veering toward the Scrum methodology of building products since you’d still need constant prioritization and re-prioritization between competing items.
The smaller the complexity of deliverables, the smaller the size, or working in a single development and design team, you should keep hanging onto the Kanban methodology of building products since you’d have a simpler time just moving Issues through their various statuses, and lesser meetings and overheads to perform to manage any complexity.
I’d recommend starting out with the Kanban approach until such a time that your team warrants the need to create sub-teams or PODs or until you reach a critical phase of 3 Products or more where you’d need to start planning your sprint and commitments.
In the next part, we’ll discuss the implementation of your Project Management board for tracking the status of requirements in your Products.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
