At Tivix we are flexible about a lot of things. With the rate of tech advancements, evolution of product landscapes and the pressure of aggressive project timelines adaptability is a requirement that we take pride in fulfilling. Part of being flexible in our case means that we do not hold all engagements to a single project management framework. We often integrate with larger teams that subscribe to versions of SCRUM and in situations where we are performing prelaunch work for an MVP our methodologies can lean towards the Kanban style of development. Regardless of the framework that best suits a given project, one thing is for sure: Tivix PMs wholly subscribe to The Agile Manifesto and this allows us to deliver great products while serving our teammates and clients well.

It is no surprise that SCRUM is one of the (if not thee) leading agile framework considering Mike Beedle, a co-author of the Agile Manifesto, wrote the first book about SCRUM just several months after the conference where the manifesto was born back in 2001. The framework stresses roles & responsibilities, daily team meetings (in person as often as possible), highly structured sprints and metrics around velocity. In my view the main goal here is project efficiency and predictability, a highly appealing model. But is it right for every phase of every project? SCRUM can be dogmatic in ways that slow down rapid development and in cases where there is little risk in making adjustments to a planned sprint, it seems logical to do so as needed. This is especially the case in the earliest phases of projects when it is the most difficult to estimate the complexity for a given feature. In these cases, spending copious amounts of time planning sprints without much (or any) data on the project to base your predictions on can be a waste of time and can end up looking like a mini-waterfall model.

Kanban Development shares many of the strengths of SCRUM, without the structure. Based on Toyota’s Manufacturing processes for JIT Delivery, Kanban focusses on minimizing the amount of work that is “In Progress” at any given time, emphasizing continual releases. It takes a team approach rather than stressing specific roles and encourages a visualized workflow based on three statuses “To Do”, “In Progress” and “Done”. One of my favorite things about Kanban is that the cycles are based on very short iterations, a key factor when dealing with dynamic project requirements. As much as I love Kanban in theory, in practice there are some pitfalls for consultants in particular. Unlike SCRUM, Kanban does not highlight the ability to estimate how long something will take because each cycle is very short and potentially varying lengths it can be difficult to systematically estimate timelines and budgets.

Both frameworks have their issues: SCRUM’s strict rules and planning can get in the way of quick progress while Kanban methods can easily become haphazard and unpredictable when working in a consulting arrangement… if only there were a combination of the two?

Scrumban! I was very glad to find that Scrumban is actually a thing but I have not found it to be very well defined (yet). It seems there are many interpretations for combining these two frameworks into a project management style that works best for a given situation. Here is a quick overview of my special Scrumban blend:

My take on Scrumban pulls standards from both frameworks to strive for:

• Accurate timeline and budget predictions
• Emphasis on prioritization
• Accommodation of change
• Quick turnaround /delivery

In consulting, projects differ depending on the vertical, organization and the structure of the engagement. These variables influence the details that create an optimal project management style however, there are some constants that allow a team to succeed. At Tivix such values are based in the Agile Principles and in concepts from the frameworks I called out above. The right mix of procedural structure and dynamic flow is essential to creating happy, productive teams and amazing products.