507 blog posts.
That’s how many items our team has created, edited, and published since implementing Scrumban.
Before we set up our system, we were mostly scrabbling to get items together from week-to-week, without knowing what we’d be working on next.
Now, we’re always 3 weeks ahead of our publishing calendar, have built our blog to over 130,000 subscribers, and have expanded our team by over 300%.
That’s why we here at Process Street will take you through this (practically new) method for managing your team and projects.
If you want a sneak preview of how we’ve deployed Scrumban, I’ll give you a hint. It’s got something to do with the Sprint Planning checklist below (which you can grab for free!)…
The basics of Scrumban
To get started with Scrumban, you first need to know the ins-and-outs of its parent agile methods; Scrum and Kanban.
What is Kanban?
Kanban is an agile method of workflow management that focuses on continuous improvement and limiting WIP (work-in-progress) items.
Originally a method of lean manufacturing, the Kanban method of workflow management is best imagined as a cork board with several columns and post-it notes. Each column on the board represents the stage a project is in (eg, To Do, Doing, Done) and each note is a project.
The key here is that everyone in the team is responsible for the tasks (there are no specific roles or “Kanban leaders”), and that projects can be added to the board or shifted around at any time.
If the team is stacked full, the board is kept as it is. If they’ve completed a project and have the bandwidth for something else, it can get added to the pile.
Alone, this can be a nightmare. People moving projects back-and-forth at will with little communication is a great way for nothing to get finished.
However, with effective communication and collaboration, you have an effective system that lets your team adapt to new projects and changes in their workflows on the fly.
Limiting the amount of work in the “Doing” column also means that your resources are focused on working on the highest priority items and getting them done before moving onto the next item.
In other words, projects don’t get started and then dropped when something else comes up. You start something, you get it finished, you move on.
What is Scrum?
Scrum is an agile methodology that focuses on using smaller, self-organized teams to achieve objectives. Originally devised for product development, the idea is to have a few defined roles (typically a “Scrum Master” and “Product Owner”) which keep the smaller teams on track and working effectively.
A good way to visualize Scrum in action is to imagine a small team of people planning a month of work in advance. They know what objectives they should work towards, and align their tasks accordingly.
As you can see, there’s a little less flexibility in Scrum than Kanban (work is set and completed) and the overall focus is at a higher-level (objectives rather than tasks). However, this doesn’t mean Scrum is inherently better or worse than Kanban.
Scrum excels in making sure that your teams are working transparently and achieving their goals within a set time frame.
The flipside is that alterations to your processes and tasks are much more difficult to deploy without putting it off for a month or more.
For example, let’s say you have an awesome project proposal that would be more effective and easier to accomplish than your current tasks. In a Scrum system, the work has already been set, so you would have to run your proposal through the entire team, and your manager, and then wait for your workload to clear enough to fit it in.
It delays iteration, and not always for the better
If you’d like to know more about the differences between Scrum and Kanban, check out our post on the topic:
What is Scrumban?
Scrumban is an agile methodology which is a combination of the set planned work from Scrum and the continuous improvement and task-focused work organization of Kanban.
Sound confusing? Don’t worry, here’s another way to think about it!
Imagine that you use Scrum to organize your team. You have, say, a month of work planned out in a “sprint” for your team to complete, with a key figure checking on you and keeping things on track.
Usually, there would be no room to change the work (or your methods) once it’s been assigned. You have your objectives to achieve, so that’s what you’ll be doing until the sprint ends.
Scrumban takes that format and allows the flexibility of Kanban to come into play.
Now, instead of having static methods and planned tasks, your workload has room to shift (either in tasks or your method) based on what works best and any new developments in your team.
It’s Scrum, but flexible. It’s Kanban, but structured and time-sensitive.
The pros and cons of Scrumban
Scrumban has several advantages and disadvantages. Some come from the individual Scrum and Kanban elements, and others which are brought as a result of combining them.
The trick is knowing how to make the most of the benefits while accounting for the drawbacks.
To quickly sum up the advantages and disadvantages, Scrumban:
- Is great for splitting large projects into bitesize chunks
- Enforces transparency
- Identifies and reduces bottlenecks
- Achieves objectives and avoids confusion through planning
- Offers less control for team managers
- Has little documentation as it’s relatively new
- Can be more difficult to track and monitor
Let’s dive into the pros and cons in more detail.
Scrumban is at its best when you’re using it to split large projects into smaller, workable chunks.
Imagine you’re working on releasing a new product feature. The timescale will, naturally, be vast and the tasks involved with it will be far beyond “create and publish the feature”.
Scrumban lets you break the project up into smaller tasks so that your team can focus on what they have the capacity to complete. No more scope creep, stacking work on overloaded employees, or losing track of deadlines.
In much the same way, Scrumban is fantastic for planning out large or complicated items. Objectives can be split in the same way large projects are, with a constant focus on what’s achievable in a given time frame (sprint).
Now, so far, I’ve only mentioned Scrum-based features. Let’s pull in the Kanban advantages and put the “ban” in Scrumban.
The use of Kanban means that Scrumban is a more transparent methodology than Scrum. This lets everyone in the team (employees, managers, you name it) see what’s going on, what they need to be working on, and who their work depends on at a glance of your project management software.
Because your work is more visible to all parties (everyone is working from the same board), it’s also much easier to spot bottlenecks.
For example, if your tasks are all going through a single point before they’re completed (eg, managerial review), you can spot it more easily and take steps to open that bottleneck.
Sadly, Scrumban isn’t all smiles and roses. It does, however, have fewer drawbacks than Scrum or Kanban individually.
The biggest drawback to Scrumban is that it’s a relatively new methodology. This means that there’s very little in the way of documented best practices or pitfalls.
Scrum and Kanban have been around for years, with teams around the world putting them through their paces. Scrumban simply hasn’t had enough time to be tested in the same way.
As such, there will be a lot of trial and error in deploying it in your team. Since there aren’t any instructions, you just have to look at the two methodologies it combines, and consider how to best deploy the new one.
The second biggest drawback to Scrumban is that it’s more difficult to track.
This is a problem as, if you don’t have an effective tracking system in place, the autonomy given by letting your team decide what to work on internally can make it hard to keep track of the specifics. Knowing precisely who has been working on what and for how long can become lost if you don’t already factor in tracking methods to your sprint planning.
The final notable drawback to Scrumban is dependant on the way you work.
If you’re the kind of manager who likes to control everything that your team does, be involved in every step of the process, and expect everything in writing three times before it’s deployed, you’ll find the technique lacking.
How to implement Scrumban
So, you know what Scrumban is on paper – great. Now how about actually implementing it in your team?
Circling back to the disadvantages of Scrumban, one of the most difficult parts of using it is deploying it in the first place due to the lack of modern documentation.
It’s hard to know what to do and what to avoid when very few people have a comparable system.
That’s why we here at Process Street are going to let you in on a secret – how our team deployed (and still use) Scrumban to consistently meet our goals while remaining flexible.
How we use Scrumban at Process Street
To prove that, we document our processes using our own product. This lets us have specific instructions to follow for any recurring task we have to perform.
Anything related to carrying out a task or fulfilling a duty to the best of our ability, our product has it covered.
However, back in 2017 we needed an easy way to track and assign projects to our teams at a glance. We needed to give our team the structure to properly plan our work, with the flexibility to continuously improve our processes and tweak tasks as we went.
We needed Scrumban.
The method we set up has endured for almost 3 years now with very little iteration. Here’s how we manage our marketing team:
- At the start of every month we have a “sprint planning” session to block out what everyone needs to be working on
- The month is split into 35 “points” of work, with 1.5 points equalling a full working day dedicated to a task
- All tasks were assigned points values (eg, 4 points for a blog post) according to how long we estimated they took
- This let us put together a solid guide for our writers and editors to follow, and allowed us to effectively scale with new hires
If you’d like to grab a Sprint Planning checklist for yourself, check out the free template below!
Those are the basics but, obviously, there is some nuance to the technique.
We use Airtable to plan and track our monthly tasks, while automatically running checklists in Process Street so that everyone knows what they have to do and how to do it. These checklists are then automatically pushed through to Airtable, giving us a Scrumban board that handles our data entry for us.
The “agile” part of Scrumban comes in when we identify an issue that needs solving.
For example, let’s say that we find a problem in our Blog Pre-Publish Checklist. In a rigid system, this would take time to uproot, edit, deploy, and train our team on the new practices.
Instead, thanks to Process Street, all we have to do is edit the template, save our changes, and hit the “update all checklists” option.
Everyone knows what to do at all times and, thanks to our powerful features such as approvals, our editors and managers can stay fully informed without having to chase up work.
In the same vein, thanks to the prior sprint planning, we have the room to adjust tasks or even shift blog posts around in our calendar if we need to. If an author has to take time off, we can see what they were working on, the progress of their tasks, and immediately swap their post to a later date if needs be.
It’s structured, yet flexible, with enough transparency to avoid the problems of self-government.
How to set up your own Scrumban system
Don’t know where to start? Not a problem! All you need are two things:
- A piece of workflow software to guide your methods
- A project management system that’s transparent
The key with both items is to use systems or software that lets anyone in your team see anyone else’s work and methods at a glance.
It’s the best way to show your team exactly what they need to do to complete a task to the highest standards, while making it easy to track and view progress.
Most importantly for Scrumban, Process Street lets you deploy changes to your processes at the click of a button. You don’t even have to train your team on the changes, as all of their in-progress checklists will be updated with the new instructions!
This is also why you shouldn’t settle for organizing your checklist templates using Microsoft Word or Google Docs. There’s no way to effectively track progress or to make sure that everyone is working from the same version of the document.
To see it in action, check out our intro webinar!
In short, it’s the best process management software on the market.
As for a project management system, you don’t have to use complex software (although we’d still recommend Airtable if you can get to grips with it).
The easiest system to use that gives you the transparency and flexibility required for Scrumban is a dedicated Google Calendar. This will let you organize your team’s tasks as events which you can assign them to, while letting anyone and everyone see what’s being worked on at a glance.
Stop letting bureaucracy and last-minute changes interfere with your productivity. Start using Scrumban.
Have you tried using Scrum, Kanban, or even Scrumban? We’d love to hear how you deployed it in your team in the comments below!