Who is Scrumban for?
Scrumban is applicable in many industries; it is not specific to a particular domain or business type. Kinalta's variant of Scrumban (SB), optimized for marketing and product teams with multiple projects in parallel. What will make it relevant to you is if you want to take advantage of the power of Agile project management.
If your organization use dedicated project managers, or you are using Waterfall project management, Scrumban might not be a right fit. On the other hand, if you typically deal with changing scopes and varying or unknown requirements, switching priorities, or you use self-managing teams, using an Agile methodology like Scrumban could be very helpful.
In fact, Scrumban is particularly suited to multi-project management, as it was designed to handle many projects in parallel. This makes it really useful for Professional Services businesses. That is, any business dealing with many projects, at the same time, for customers or internally requested. For example, a digital marketing agency may have multiple campaigns going on for several clients, and team members work, based on expertise, on several tasks throughout campaigns. Another example is an engineering or architecture office, working for several clients at the same time, and dealing with priorities and scheduling conflicts.
What is Agile?
Agile is not a methodology; it is a philosophy. Although ideas coming from Agile project management are being used in more and more industries, its origin is the software industry. As mentioned earlier, Scrumban is not specific to this industry though. However, it is important to understand the context and origin behind the Agile approach.
Because it is not a methodology, you cannot learn “Agile” and apply it to your daily job. Agile is a philosophy described in a very short Agile Manifesto. In it, the group believes self-organizing teams are the best solution to achieve agility. It also believes in technical excellence and continuous improvements for the team, learning and improving its own processes.
Agility also means the ability to sustain a constant pace of production indefinitely. And of course, almost above all, Agile is about satisfying customers, including welcoming changing requirements even late in the process -in order to satisfy and give customers a competitive advantage.
This philosophy is in sharp contrast to how projects were managed before. In the past, a deep hierarchy would organize projects, with several levels of managers. You would study requirements, possibly for months or years. Once started, projects would have little flexibility in scope or delivery time.
That being said, Agile is not a panacea. In fact, it is often very difficult to transform an organization into a successful Agile organization. In any case, its goals are clear and when you achieve them, you are in a very powerful and competitive business.
Scrumban is an Agile methodology
Agile is a philosophy, and to implement it in your organization, you should use a specific methodology.
There are many. They are often, but not always, geared toward software engineering. They include : Scrum, Kanban, XP, Crystal, DSDM, FDD, etc.
Kinalta's Scrumban, or SB is a methodology, and it truly implements the Agile philosophy.
SB core concepts
There are a number of prerequisites for SB to work. The organization should understand the main reasons Agile exists and it should decide to embrace the philosophy, if not the case yet.
For example, a core concept in Agile is to welcome change, at any time during the workflow. If team members and the organization resists, it can hardly be called Agile.
SB requires self-managing teams. Teams may vary in size from one single person to 8-12 people. With larger teams, it becomes more difficult to self organize. It may be preferable to separate people in several independent SB teams. There is no project manager. This is sometimes misunderstood to mean there is no accountability. This is not the case.
A team may have a coordinator whose role is to facilitate implementing the methodology, somewhat similar to the Scrum Master in other methodologies. This is typically not needed though. In SB the team itself should coordinate efforts, as a group, and more importantly, monitor progress as a group. SB expects a flat structure, at the level of project management. The emphasis is on communication and awareness.
Open access to information
This is why SB prefers a completely open access to all information relevant to active projects.
Every document, file, email, should be accessible to everyone in the team. This open access is a prerequisite to enable real team decision. Organization implementing SB should use tools and infrastructure enabling this access to all team members, local or remote.
Dates and calendar
Although dates are often important for projects and in real life, SB treats dates as secondary and merely targets. This is often a point of conflict when introducing the methodology. It is important to understand dates introduce rigidity. The more dates throughout projects and tasks, the more rigid the plan becomes and worse, everyone’s mindset about it.
Instead, consider dates as wishes. In reality, almost all dates are negotiable. Make dates optional and secondary, it becomes possible to rearrange tasks, projects and resources for the real goal : satisfy customers and succeed.
This is not to say SB ignores dates altogether. They are important targets and a way to monitor progress, lateness, or efficiency. The methodology simply considers that dates have nothing to do with effectiveness.
Effective and Efficient
SB strives to be a methodology to achieve both effectiveness and efficiency.
In fact, everything in SB is about achieving these two goals.
Effective: (adjective) successful in producing a desired or intended result.
Efficient: (adjective) achieving maximum productivity with minimum wasted effort or expense.
Kinalta's Scrumban : being effective
SB is a true Agile methodology. This means the primary mission is to satisfy customers. This satisfaction is clearly understood as delivering the expected and intended output (what the customer required). Therefore, above all, SB strives to achieve effectiveness, before timing, dates, or other considerations. An important part of the methodology relates to activities to ensure the team is effective.
In order to ensure effectiveness the methodology expects the team to follow a simple but strict process.
Assigning a task
Technically a task is indivisible in SB. It might refer or relate to multiple tasks, but in itself, a task is self contained and it cannot be broken down. Also, as mentioned before, a task is either not assigned to anyone (yet), or it is assigned to a single person, never a group of people.
This is critical to enforce accountability, tracking and to monitor progress.
A fully working SB team is self-organizing and a flat structure. Within this structure anyone can take responsibility for any task pending. In other words, team members can assign any pending task to themselves. Of course, communication and coordination with other team members is important, whether during a daily meeting or using Agile SB software.
A task has both an assignee, and a member responsible to approve the task. By default, if not specified, self approval is expected. Otherwise a specific team member (single person) is tagged as responsible to approve the task.
Before working on any task, or any project, the first step is to formally “Accept” it.
Accepting a task
In the regular course of running operations, an SB team will have to process tasks and projects.
Acceptance means, the team member assigned to a task must evaluate all inputs received for the task. These can be files, documents, emails, notes, transcripts of conversations etc..
A task remains in “accept pending” mode until it is fully accepted, or deleted. Nobody should work on any task in accept pending mode. To accept a task, team members should communicate with customers to clarify intent, get documents, and importantly, clarify the expected output. This step does include negotiation.
A customer is not a tyrant, it cannot and should not dictate what the team does.
There is a difference between “requesting” and “dictating”. Acceptance is about negotiating this difference and agreeing on goals.
As mentioned before, customers may be external or internal to the team. When a team member assigns a task to another one, this is a request. Any team member is required to accept or refuse a task. Therefore the same process applies whether the task comes from a client or from inside the organization.
Measuring success for the task will be about comparing the actual output and the expected output. So, to accept a task, both input and output must be clearly defined. Once accepted, work can begin.
Because SB is truly Agile, once work starts, it is still possible to redefine input and output. But, this automatically triggers a state change : the task goes back to “accept pending” mode. Acceptance must be acquired, negotiated, before resuming work on the task.
Accepting a project
For a project, thanks to self-similarity between tasks and projects, acceptance follows the exact same process. Everything said to accept a task is exactly the same to accept a project. Crucially, no work on a project can start before the project is formally accepted.
That being said, a project is not assigned to a single person. There is no project manager. The team owns every project. This means acceptance is the responsibility and duty of the entire team, not any particular member.
It is very usual to have a main contact, or a coordinator for a project. This person can take the role of main interface between the project’s customer and the team. But this coordinator does not own, or direct the project, the team does. Almost all SB projects have a coordinator as it is a great way to smooth out communication and advocacy for the project (for example when it comes to priority, quality level and assurance).
Working on a task
Once accepted, work on the task is possible. It does not mean it happens right away. When tasks happen is covered in the “being efficient” section of this methodology.
In the context of effectiveness, team members must always monitor their work against the expected and intended output.
All tasks must be approved in SB. This approval may be a simple and quick formality, or require a longer step to validate it.
A task “Done” means when the task is considered complete, output verified and delivered internally or externally.
When a task is marked “done”, it is not the final step for it. That being said, approval can be swift and a simple formality. If the task was tagged for self-approval (see “Assigning a task”), when marked “done”, it becomes immediately “approved”.
Any task may require more formal approval though. In this case, self approval is not authorized. When marked “done”, the task is submitted to a previously selected team member. This member is then responsible to approve or re-open the task (it is deemed “to do”, again). In order to approve it, input and output are considered, including, when needed, communication with the customer (internal or external).
Kinalta's Scrumban : being efficient
SB is a multi-stage process. It includes prioritizing projects, backlog, tasks within projects, and scheduling everything. The methodology is a lean project management system. It focuses on eliminating waste of resources and time. In order to do so, SB leverages a very powerful system: Kanban.
Kanban fits perfectly within a framework like SB, even though Kanban is not a project management methodology. SB provides rules and policies to organize and prioritize projects and tasks, while Kanban provides a system to visualize and distribute tasks as well as follow their progress.
The visual board system provides most of the efficiency in SB thanks to its pull nature and limits in work in progress. Scrumban is another methodology using Kanban boards to bring efficiency to Agile project management. However, we believe SB is better if you manage more than one or two projects at once with your team.
This is because SB works with three levels of Kanban simultaneously.
The top level in the picture is the Kanban of all projects. Each card represents a single project. There is a small icon on each one; clicking on it will open the Kanban In the middle. This second Kanban represents a single project.
At the bottom, the third Kanban is a little different. It is the personal dashboard of a single team member. On it, each card is a task coming from, possibly, multiple projects at a higher level.
With Kinalta’s Kanban, you manipulate each Kanban separately, but the software keeps everything in sync and reschedules everyone's dashboard constantly, using Artificial Intelligence.
This synchronization is why you need a specialized SB software; it is difficult to do manually with standard multi-Kanban software like Asana and others, but not impossible.
Then, the first step is to prioritize all projects, or more accurately, to review all priorities, because in SB, priorities might change every day, sometimes more often in some businesses.
Here, we mean priorities strictly for projects, not the order or priorities of tasks within each project. In other words : should project gamma be worked on a little more than project delta? And less that project epsilon?
This list of project priorities then dictates the order of the total list of tasks to do (based on the project they belong too).
Second step is to review all pending tasks (not done), in all projects. This review is constant and you do it in the middle level of the Kanban stack illustrated above. The review happens all the time, and by all team members. Remember, team members create tasks all the time, typically as related tasks for a project or another task already declared.
Pending tasks fit in the first column of the project’s Kanban.
It is a good idea to review pending tasks, quickly, during daily meetings if you do have daily meetings. When using a software, typically, you can avoid these meetings.
Once you start on a pending task, you move it on the board in the second column. This is the normal way you use Kanban boards.
In SB you should also assemble tasks in priority groups. A priority group is simply a set of tasks that can be done in any order, within the priority group. The other rule is that you must complete all task in a priority group before working on any task of the next priority group.
By convention, priority group T04 must be done before priority group T05 and after priority group T03. In other words, the lower the number, the higher priority.
The third step in SB is scheduling
The goal is to update the third level of Kanban. This is the dashboard level. Every team member has his/her own Kanban (shown at the bottom on the 3D Kanban stack above).
In this board, you only see your tasks. The first column is the list of tasks scheduled for you. This is not the list of all tasks assigned to you for all projects. Based on all projects and their priorities, It is the list of all tasks that can be assigned to you at this point in time.
This is where, again, a specialized software is critical. It would be inefficient and slow to reshuffle these tasks in your dashboard every time a project gets a higher priority.
Thanks to this automatic synchronization, the team is always working on the right projects, the right tasks, at the time.
Please note that once you place a task/card in the second or third column of your dashboard Kanban, it will remain in it, assigned to you. It stays there even if the task’s project priority change. Once you start on a task, it cannot and should not be removed automatically from your schedule!
That being said, you are free to place a task back to previous column, place a hold on it, freeing you to work on something else.
The dashboard Kanban automatically synchronizes the project’s Kanban. You always have clear visibility on current status of all projects, all tasks. This progress is also fully transparent so the entire team is kept informed.
Also, there is a concept of time-boxing at work. It is there to prevent working on a single project for too long. Working too long on a project is an anti-pattern, because it might block progress on all the other projects.
Importance of the present
The methodology is really focused on the next 24h-48h. What matters is what you are doing now, and what you will be doing soon.
This focus is a significant benefit with SB. You always know what you should next.
If your focus list is empty, or about to be, you should check Kanban boards for all active projects and review pending tasks to pick up your next tasks.
Therefore the efficiency comes from the fact, SB will try to get all team members busy for at least the next 24h and 48h if possible. This makes the overall work effort, for the team, constant and sustained.
Why use Agile Scrumban?
Kinalta's Scrumban, SB, is a true Agile methodology and framework. The three levels of Kanban boards fulfill the Agile vision of maintaining a sustained level of production / operation with a focus on delivering value -i.e what your customers want.
It does enable any service oriented, project based, organization to be more effective.
It does bring an emphasis on customers satisfaction by making the right efforts to deliver the expected and intended output (project or service).
It does this while using operations management principles and processes. These processes help the organization to be efficient. SB teams are efficient because they focus on the present, keeping team members busy on the right project, in the best order decided by the team.
Unlike other Agile and non-Agile methodologies, is designed to handle multiple projects at the same time, with fast changing requirements if needed, with cross-functional, self-organizing teams.