Why we ditched Scrum, in favor of Kanban in JIRA

Warning: don’t misinterpret scrum for agile as a whole πŸ™‚

Around a year ago I wrote a yearly retrospect on how the workflow at SkuVault is organized, and how we set up our jira boards to work in sprints.

sprints and their goals

There was no Kanban backlog at the moment, and we used Scrum board as an improvized scrumban tool: we had the sprints, which were treated as folders to fit tickets in some time period. Classical sprints were not suitable for our workflow, I mentioned the reasons in Year Retrospective @ SkuVault. So that sprint-folder system was great, visible and allowed us to predict.

2017-07-16 21.39.59

Yet, in a year period the signal that our approach (sprints as folders) doesn’t quite work appeared – there was a number of tickets migrating from sprint to sprint being rescheduled over and over.

Allow me to add a small note here on SkuVault specifics: There are different categories of work, and planning a common roadmap doesn’t quite work either: we get different priorities from different departments (QA, Product Management, Services and Angry Clients, Services and Happy and Willing to Pay clients) – so the urgent ticket scope inflates. Urgent tickets may require distraction of a developer working on some client request, which shifts the timeline for delivery. So, in a nutshell: there is no unified roadmap between different categories or depts – there is a near-term plan only, with each category having it’s own stack of priorities. Now add to this a remote team that works in collaboration across atlantic and with the timezone difference of 9-10 hours πŸ™‚

worldmap
SkuVault is a distributed team of awesome people, spreading across 9 timezones, or sometimes more. Notice how pathetic I am when it comes to image editing. Those are not cute animals – those are coat of arms symbols, lol πŸ™‚

So a question is: how to remodel the workflow to reflect the specifics?

Buckets and Kanban

We came up with the idea of buckets: basically those are categories of work, originating from different departments with separate product owner responsible for stack of priorities.

Last year Atlassian finally realised the scenarios teams use their product for. So, Backlog for Kanban was born out of desperate cry of thousands of PMs, Teamleads and other people who cannot develop themselves and just drag and drop tickets on the boards (/sarcasm).

The feature came out quite handy and we were able to merge our workflow with our development process IRL.

kanban_backlog_glory
Finally, there’s an option to see upcoming backlog you can both groom and plan inside, and drag that to ToDo as the near-term goals! Don’t forget to estimate that properly πŸ˜‰

Backlog Kanban allowed us to re-evaluate a lot of backburners that were hanging out there, never getting into the sprints. It also gives us a cleaner board – cause you can store current workload apart from near-term plans, yet in the same board. It’s something you already get with scrum boards, just without sprint management.

Current State

We attacked backburners and development scope from two fronts:

  1. created a separate IDEAS project, where tickets were getting fully fleshed out prior to development;
  2. moved all of the backlog tickets that were on the shelf in development projects back to the IDEAS, to re-evaluate;

This + we’ve added Buckets System, with the support of limited number of devs in the pool for each bucket. I’ll try to write a separate post on how Buckets work in our company later (spoiler alert: they work only as indicators of ticket origins, otherwise – they are kind of not really helping, as of the current state, after some teams shuffling πŸ™‚

Boards, Workflows, and two Backlogs

We’ve got two workflows – one for preparing the ticket for ready-to-be-developed state, the second is for development itself.

Each workflow has it’s own board – as you know, boards are the best ever unicorn rainbow tool to show state of the project from a particular angle.

So two boards reflect those workflows.

IDEAS Board

(Also called pre-development), managed by Product Management. Includes it’s own backlog for backburners, that we put in the shelf for some time (or close to forever); Sign Off, Detalization and Formalization, Architecture Review and finally Ready to Schedule states. Each step has a description and a format of how it should look.

pre-dev-workflow

The point of this board is to reflect status of every single idea that we decided to evolve into a feature, and to see the bottlenecks in Product Management workflow.

pre-development board
Ticket on the right is not violet – it’s just blocker by another Core task
PDM Workflow

Establishing that IDEAS board was also a result of creating full Workflow for Product Management, without letting the ticket out of the IDEAS project and into main SkuVault development project, until all the details and edge cases are fleshed out (well, you caught me – there is no chance you get all 100% of edge cases, but you should try as hard as you can).

By creating standards for each step of formalizing the ticket, we’ve ensured the consistent quality of ready-for-development tickets, which ensured that they won’t be put on hold until clarification from API partner / Client / Product Management. You don’t get big stream of tasks pouring into development, but the quality of such tickets lets developers be distracted less and be more motivated, because who wants to switch context and work on something unfinished.

Development Board

As I pointed out in previous posts – development board is pretty much untouched -> if it works, don’t break it πŸ™‚

SkuVault v1.7 - JIRA 2016-06-08 15-12-47

But the utilization of Kanban Backlog in JIRA came quite handy for both of the boards: you are able to have a set of tickets in the backburner, still in same project, but not wasting ginormous amounts of space on the board -> you just access all backlog via a special planning view.

backlog_predev
Pre-Development Board Backlog

While IDEAS board has a backlog with things, that should sit on the shelf for some time, Development board utilizes kanban backlog in a slightly different manner: I store optimization tickets that we need to check every couple of weeks / months there; as well as User Stories for Epics, that are still in IDEAS, that we didn’t get into development yet; or it’s a very handy way to form a pool of tasks for upcoming developers.

kanban_backlog_glory
Development Board Β – Backlog. Two Magento versions support is on hold -> we’ll reevaluate them in the coming months – they’re waiting for their turn.

 

JIRA also support swimlanes for boards, which is utilizied by us in a manner of separating projects one from other:

development board
Three projects in Progress for Shawn -> Lots, QC Improvements, Shipments. The higher the project’s swimlane – the higher it’s priority.

..in a nutshell

  • We’ve ditched sprints, in favor of Kanban. It’s much easier to not pointlessly drag and drop tickets from one sprint to another, if they’re not ready. As I wrote, Urgent tasks needing on call devs contradicts with uninterrupted scrum approach for developing concrete chunks of functionality in a given timebox (mind the fact that scrum and agile as a whole deals with deadlines badly, while we have deadlines most of the time);
  • Kanban gave us differentiation by projects on one board, without making the board too crowded. Scrum boards give that too, but count the hassle of moving unfinished tickets from one sprint to another, which doubles the maintenance work;
  • Kanban Backlog is a great feature, allowing us to manage all tickets in the project. We could have done this in two boards (one for new tickets to be moved to agenda or closed, and another for development / formalization itself) – but now we can manage all tickets in one. Neat.
  • We had an Urgent Board (Kanban Workflow), and Development in Sprints (Scrum) -> now that we moved Development itself to Kanban, we were able to unify the boards, and everything, from minor to blocker tasks, is visible on the same Board! This is great!
  • Never use scrum rituals just for the sake of rituals. We didn’t use sprints for the sake of sprints, we approached sprints as folders and timeboxes. However it’s a common mistake, while management or teams create a cargo-cult for scrum. Most likely you’ll use different practices and methodologies over the time, and finally will come to a hybrid approach that makes you efficient.
  • There are different companies, and certainly there’s no silver workflow bullet for all. So given the maturity / infrastructure / tech. stack / staff – you should model the workflow related and reflecting the flows inside that particular company. SkuVault is changing, growing, scaling – and so is the workflow. Different depts can have different workflows – and we reflect that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s