Hey Reader,

Long time, no see!

If you read my last email, you know that took a couple of weeks off to enjoy some time with my family. And I made a long trip to... Kazakhstan.

It's practically on the other side of the world from me. So only 20 hours of travel time, and we've arrived to a burning hot city in the mountains.

Vacations are fun and all, but I got a chance to meet up with an Agile team my brother works with to help them with their Kanban implementation.

And I thought it can be an interesting topic to share with you.

I'm planning on making a video about it, but since you are on my newsletter list, you get this info a bit in advance!

(and if you're following me on LinkedIn or on Threads, then you might have seen a post about it already)

Anyway, I sat down yesterday to note my findings and my thoughts on this experience.

​

The Kanban board setup

First of all, I was quite impressed by the setup they had for their board.

It took three walls full of sticky notes and posters (take THAT, flexible office space).

The team was using the board every working day during their Daily Kanban, as they called it.

Here're a few things that I noted:

There was a small portion of the wall dedicated to the Product Backlog.

It didn't have everything in there, and it wasn't prioritized to the point that would make my heart melt, but it was visible and accessible to the team.

Work-in-progress limits were set per person per day.

Each team member had three sticky notes with their face that accounted for 2-3 hours of work. They used these notes to put on tasks based on their approximate estimations of effort. Basically, they were trying to see how much work they are realistically able to accomplish within one day.

The team was also tracking other tasks taking time like meetings, and their face-sticky notes would sometimes be distributed on those tasks instead, making it immediately clear how much time they have left on other tasks.

They were using checklists to track progress of tasks.

It was a bit different in how they organized their tasks from what I'm used to. Instead of using sub-tasks and moving each sub-task from To do to In progress to Done, they were using checklists for bigger tasks and checking the items they completed.

Definition of Done was used for some complex steps in their workflow.

Another nice use of the board was a kind of a Definition of Done attached to each step of their process, so that they can quickly check if everything has been completed before moving the card to the next step.

Retrospectives!

And another extra point goes to them for having regular retrospectives! Scrum, Kanban, or anything else - retrospectives are essential.

They also had some fun rules set in place. Well, not all of them are fun, but, here's what I mean:

• Everybody had to fill in the information discussed and updated in Jira within 30 minutes after the Daily. Yes, they used Jira as a support system for additional information, and to also have a digital version of their work.
• If someone was late to the Daily, they were to give out a token to the team that can be used to ask for a favor at any point in time. Fun fact: some tokens became almost like collectibles from people who are rarely late.
• Those who weren't able to join in person, joined on the phone so they could still see the physical board.

Nothing is perfect

Of course, no implementation of any system comes without challenges. And as I often say - it doesn't matter where we are in the world, in the end, we all face similar challenges.

So I'm sure you'll recognize some of these challenges faced by the team in your own work:

• Lots of dependencies on others that were out of the team's control. The biggest dependency was on their sponsors and clients who needed to review the work before they could call something Done (pssst... I have a video on dependencies coming out this week). That was becoming quite frustrating for the team because they had a task just sitting there for weeks on end, blocking their Work in progress limits and just looking bad.
• Often they received new requirements on previously approved projects. Often these requirements would force them to re-do a lot of the work already done. And some of the requirements were in the form of "Wouldn't it be cool if we did this?!". The deadlines, however, didn't change.
• It was unclear what the progress is on some of the tasks and projects. One of the key points of having a Kanban board is to visualize the workflow. While their board was impressive, it actually got a bit complicated. It provided a lot of information, but not a good high-level view of what's going on.
• The Cycle Time was too long to allow them to respond to changing requirements and plan ahead (77 days!). They also didn't track it regularly and had old numbers. (I can totally understand why - if it's so long, what's the point anyway, right?)
• And last but not least, the requirements were not really properly documented anywhere, and the desired end result changed along the way (see one of the previous points). While they would discuss everything with the client before starting the work, acceptance criteria for their project weren't exactly agreed upon. Of course, having changing requirements is normal in an Agile environment, but in order to adapt the plan we need to have a plan so that we can adjust the rest of the expectations.

​

There's no one solution, only some good practices

I didn't have much time to really dive into how they work, but I tried to offer some suggestions and new ideas that can inspire them to make some positive changes.

I talked about a few key points that can help address some of the challenges they are facing:

Simplifying the physical board to show clear progress...

...and using digital tools like Jira to add details. Since their physical board got very busy and complicated, it no longer provided the visibility it's supposed to. So I talked about the goal of having a Kanban board.

They were already using Jira, so using the physical space for quick visual representation of the progress and using Jira for more details seemed like an easy first step.

Planning for shorter periods of time.

Since their cycle time got so long as to almost reach 3 months, it was difficult for them to really plan ahead. I asked if they could be planning for sprint-like time periods (not necessarily using Scrum) and that their progress that way.

Of course, that would require some extra time on refining and splitting work. But it can bring real benefits for proper planning and forecasting.

Using epics and sub-tasks.

This can truly help with the organization of their work and documenting customer needs and wants. I talk a bit about using Epics in some of my Jira-related videos. But it seemed like a missed opportunity since they weren't using that functionality in Jira yet.

And also to cover the previous point on planning for shorter periods of time, they would be able to split the epics into smaller tasks and keep track of the progress of the whole epic in one place.

Epics can also help keep track of progress when new requirements are added. In this case, when something like this happens, they can discuss it with customers and show how it impacts the plan and progress. In Jira they can also use graphs to represent it (like Burnup, for example).

Take dependencies out of the process and plan for them as separate tasks.

If they use epics, they would be able to track extra tasks like dependencies in one place but not crowd their Kanban board with non-moving tasks that are waiting on someone else.

​

What are your thoughts on these suggestions? Do you think this can help the team be more successful?

If you have a Kanban implementation in your team or if you are considering having one, I hope that these insights from my trip to Kazakhstan can help you.

Stay tuned for the video on this topic where I'll be sharing even more details about this experience.

​