Welcome to the Jira for Designers series, brought to you by Design at Scale™—Academy. After the basic intro(↘︎Link), let’s dive right in. Today’s article will examine the very principle of Kanban. Before we dive into the topic, a little refresher. Design as a discipline is time-sensitive and fully dependent. That means that all tasks need to happen in a predictable sequence. We can not design the book without a typeface – in the digital world, you can not design a page without understanding how many items will be on the page. Also, each task will take a certain amount of time (segment, later described as increment) that is organised in a very specific manner – sequence(↘︎Link).

What is Kanban

Kanban is a popular framework for implementing Agile software development. It depends on real-time communication and full transparency between all team members. Work items are represented visually on a Kanban board, allowing team members to see the state of every piece of work at any time(↘︎Link). Let’s break this down a little.

Work at any time

This means that Kanban is not time-restricted, and therefore, a holistic discipline like design is perfect for its implementation. That way, the task can stay on the board as long as it gets finished.

Before, During, After (ToDo, InProgress, Done)

As with any human action, there is before, during, and after. We often refer to this as a Backlog, ToDo, Doing (In Progress), and Done, allowing every party to easily understand where the task is regardless of priority, dependent, or any additional parameters.

DoR 

Whatever is marked “Done” will become DoR – Definition of Ready(↘︎Link). The definition of ready allows Certified Product Owners(↘︎Link) to grab this piece of work that has been delivered and schedule it for development. Achieving a clear and very transparent “Stage and Gate.”(↘︎Link)  

Why you should care

As mentioned above, in most organisations, the design function still has premature settings in regard to operation. Inevitably run by project managers that have Prince2(↘︎Link) or some basic Agile(↘︎Link) or Scrum(↘︎Link) course training at best, claiming that everything is under control. 

Is it really?

Without judging anyone or being extremely critical, you can run a simple PM test for yourself: 

Do you know what are you doing?
(do you know what others are doing)
Do you know when it needs to be delivered?
(how much time remains on your task)
Do you know the dependencies of the task?
(are you blocking anyone, or is anyone blocking you)
Do you know the complexity of the task? (↘︎Link)
Do you know the priority of the task or tasks? (↘︎Link)
Do you know what blockers you or others have?
(Is someone blocking you? Do you block anyone else in the team?)

If the above questions happen to have YES, and therefore, knowledge is shared, you are probably in a good place. If, for whatever reason, it is more NO, you should be aware of the possible implications and impact on your design outputs(↘︎Link). Because it is you who needs to work in an appropriate, informed environment to deliver optimum results, this directly affects your performance and, most certainly, your output. A simple suggestion here would be the following:
1/ If you have Kanban, ask these questions to your PM/PO 
2/If you do not have Kanban, set one for yourself (paper one to start) 
3/If you are completely at the beginning of the project and nothing is in place, do not ask for permission and set one for yourself

Where to use it

Kanban is great for any type of design work that does not need to be time-boxed. Let me be more specific. The task (let's say designing a search feature) could be quite a big task and needs to be defined as research, analysis, schemas, wireframes, branding, UI, prototype, etc. These are all separate tasks of one epic(↘︎Link). It is better to divide these into small tasks so the team knows what you are doing and how long it takes. Working on the search for 6 weeks and saying on a daily standup, “I’m working on the search”, helps no one. Actually, it has two side effects:
1/No one knows what you are doing – demoralising and confusing
2/ It is turned against you by people not knowing what you are doing. It seems like you do not know what you are doing, and it raises suspicious questions.
An example here would be: 

I’m working on the search feature for the desktop. The work is calculated for 4 weeks and includes the following tasks:
– research&analysis
– schemas, wireframes
– branding, UI, prototype, etc.,
each taking 3 to 4 days of my time.

I’m starting with Analysis as I have just delivered the research – here is the link to the ticket and summary of my work(↘︎Link).

Where not to use it

If you are in a highly regulated and time-sensitive environment, Scrum(↘︎Link) will be more efficient as you’ll time-box the task, and Sprint will define how many tasks you are able to finish in a given timeframe(↘︎Link). Many teams run sprints using Kamban and vice versa. It's a shame that there is one way or another. It clearly shows the maturity of the design and development team(↘︎Link) and immaturity at many different levels.

Example: Those running things correctly can move timeless tasks from Kanban once DoR to sprint and continue the development of features in different functions and environments. 

Benefits

Running Kamban at the organisation (whether it’s an agency or product team) allows you and your team to be aware of what is coming. Equally, you’ll have a greater understanding of sizing, timing, and resourcing of the delivery – well, let’s say, better than without it. You can be absolutely certain you’ll increase transparency across the team by putting your tasks in one place. Quite likely, you’ll start the first pilot for yourself – a managed design team that, in all cases, reduces the PM/PO function to a minimum. Allowing the CPO(↘︎Link) to take the more important tasks to senior stakeholders(↘︎Link) enables budget and defines a high-level roadmap(↘︎Link). These are the primary benefits of having the Kamban at the agency(↘︎Link).

As for the Product teams, the Kanban can help service designers, researchers, or Design System units feed more production-based delivery settings that usually run the scrum. Leaving hands free to people who have a completely different mindset from those who define the big picture and those who simply deliver it. Simply put, big picture = Kamban delivery alongside engineering colleagues = Scrum.

XDD & CPO Advantages

As the above shows the obvious benefits to the business, there are still few that specifically help CPO(↘︎Link) and XDD(↘︎Link). Depending on the partnership and the way the team is managed, the CPO often communicates UP, whereas the XDD communicates DOWN(↘︎Link). Maintaining this balance allows both parties not to cross each other's decisions, and it creates a greater balance in the team. Firstly, making informed decisions boosts morale and increases productivity. Secondly, the experience drives the user objective and key customer objectives, helping businesses to be more Behavioural (↘︎Link). This alone has an advantage and builds an experienced team with greater room for research, service design, testing and prototyping(↘︎Link). If you are in the feature factory and you are only on the time schedule with constant changes, you can refer to a CPO as captain and help her/him drive the ship in the right direction. Above all, it’s about collaboration. 

Do not make this mistake.

So many teams make the same mistake over and over again. They start with Kanban in Miro, Murro or any other whiteboard, believing that things change. Without updates, dependencies and sharing the impact you post, the board is just another dump yard to blame the method that does not work for you. Where, in fact, you haven’t made the method benefit your team. And for your team to take full advantage of the impact it can bring. One simple change has allowed me to speed up the operation of one design team 3-5x times. No tricks, no agenda, no jargon, no buzzwords – a simple stream of tasks in one place with BS.