Since its inception in 2001, the Agile Manifesto and its supporting twelve principals have encouraged many organizations to move on from legacy Waterfall processes and adopt Agile Scrum. At agiledoyens we feel that Kanban is the next evolution of Agile and many of our solutions center around Kanban principals.

I often see organizations take two of the Agile Manifesto principals very literally and as a result they end up with every Agile team executing their work very differently and independently from one another.

  • Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

In time, configuration of Agile management tools such as Jira and Rally becomes very difficult to administer. Every team ends up with their own set of workflows, custom fields, and operational definitions. This makes standardized reporting across the organization all but impossible.

When questioned about this inevitable outcome, the justification often centers around those two Agile principals and you’ll hear folks say something like “We want our Agile Teams to be self-managing and self-directing so we give them a tool and let them configure it to meet their needs.”

As a young Agilist, I had no good reason to argue against that position even though the outcome was obviously less than desirable. Since the early days of Agile I have implemented some form of Agile Kanban in Finance, Healthcare, Hospitality, and E-Commerce industries. Fast forward nearly a decade and lots of gray hairs later, and I can now confidently say that it is very possible to create a basic “kanned” solution for every Agile Team in any industry without infringing on their ability to self-direct or self-manage.

Don’t take my word for it – the introduction of Scaled Agile Framework (SAFe) has already proven it. Multiple teams attending PI Planning events, operating on the same Sprint cadence, etc. directs a level of standardization that all teams must follow. However, even the most diehard Scrum advocates must accept that upstream workflows that Product Management typically owns (Initiatives, Epics, Features, etc.) are not executed using Scrum. Product Owners don’t conduct Sprints, hold Scrum ceremonies, or point portfolio level work items. However, they do typically view status and progress via a visual Kanban board and the overall customer value stream from Idea to Delivery is usually viewed as a single continuous flow Kanban system.

Kanban In a Kan (KIK) is SAFe for organizations that can’t afford the cost of a full SAFe implementation or want a more light-weight, stream-lined process for managing their work. Kanban In a Kan is like a can of beans. We provide the basic structure that your organization can fill with whatever type of beans you want. Whether you choose French Cut Green Beans, Yellow Wax Beans, or Brown Sugar Baked Beans, KIK delivers a “kanned” Agile tooling solution in industry leading systems based on a standard Agile Kanban workflow that you then customize to fit your company’s unique place in the market.

Kanban In a Kan Overview

Let’s start with the basic workflow for a value stream. This flow is largely applicable to any Product, in any organization, in any industry.

This basic workflow can be broken down to include a few more detailed steps and applied repeatedly over a Product’s lifecycle.

The Development Service is where you want to allow Agile Teams the flexibility to self-manage and self-govern. Let teams decide for themselves to execute Kanban or Scrum and let them decide what their workflow looks like.

The only guidelines being that all work must start on a Backlog and there must be a standard definition of what Done means. In a robust CI/CD environment this means deployed to Production and that does not necessarily mean live.

While the Agile Teams depicted in the green circle above may be conducting Scrum, the entire value stream is not Scrum. It is inherently a Kanban system that amongst other things, should limit work in progress (WIP) and measures the overall Customer Lead Time from Idea to Delivery.

The upstream workflows for Initiative and Features should be standardized across the organization so that status and financial outcomes mean the same for every Product in the organization. This is the part of the overall value stream that should be “kanned” across the organization.

SAFe is famous for their workflow diagrams and by definition, is designed for Agile at scale. Kanban can scale as well. And when you compare the overall picture of SAFe vs. KIK it’s easy to see the value of the simplicity behind the KIK solution.

Bookmark our website for upcoming details about agiledoyens Kanban In a Kan solution for Jira Cloud, Jira Server, and Rally.