Coaching an Agile team halfway across the globe

📌 Have you ever wondered how far agility goes?

Let me take you on a journey to the other side of the world map.

We’ll be traveling from Toronto, Canada, to Almaty, Kazakhstan, to coach a team on using Kanban.

We see the worlds Agile, Scrum, Kanban used everywhere. it’s the new way to work.

Almost every company is jumping on the Agile train.

Is it happening across the globe though?

Well, this time I want to take you with me to a team located over 10,000 kilometers away from where I am right now.

To Central Asia, the Republic of Kazakhstan.

So I went to Kazakhstan for holidays, because, why not, right?

And during that vacation time, I got a chance to work with a local team on their use of Kanban.

It was a great experience, very real life, and very insightful for me, that’s why I thought it would be something you’d be interested in too.

This video is a bit different from what I am usually doing on my channel, because I wanted to try something new and I really hope you like it.

This video is of course educational as I will be giving you some practical tips and advice on coaching a team and implementing Agile practices.

But stay until the end as I’ll be sharing some fun facts about the country and some beautiful shots of the mountains that surround the city.

I have split the video into four parts to keep us on track and, you know, to make it easier to follow.

Each part builds on top of the previous ones.

🔵 Part 1. The impressive Kanban Board set up the team has implemented.

🔵 Part 2. My coaching approach to working with the team in the short amount of time I had.

🔵 Part 3. The summary of the key challenges the team is facing.

🔵 And Part 4. My recommendations for solving some of the challenges.

Let’s start! 🙌

Part 1: The impressive Kanban Board setup the team has implemented

As I said before their setup really impressed me, so I have to explain it in detail.

I’m sure you can pick up some new ideas for yourself to implement.

Anyway, the whole setup included not only the Kanban board that showed the workflow and the processes, but also included the backlog of work on one wall, and also rules and other notes on another wall.

In total, the board took 3 walls of space.

I honestly think it’s the first time I’ve seen this kind of sophisticated setup. Ever.

And I’ll tell you how they actually achieved it!

I think the most impressive part for me was that they actually actively used it.

But let’s not get ahead of ourselves…

Let me recreate the board. I mean, a simplified version at least.

So here is what we had: on the left hand side, they had their backlog, very high-level.

They even had a section specifically for the technical debt.

I don’t think it’s a good idea to separate the tech debt like this, but it’s good that the list existed and it was visualized.

Then on the middle board, the main part, they had their workflow, that went something like this:

🔵 Before analysis ➝ Analysis ➝ Implementation ➝ Demonstration to the sponsor ➝ Refactoring ➝ Testing ➝ Deployment

🔵 They also had a couple of post-deployment steps that sometimes needed to be tracked on certain projects. So these were IT validation ➝ Result analysis

They’ve defined a few rows for different types of projects because their work-in-progress limits were also applied on that level.

Like, they would only work on a single project of a certain type at a time.

And, of course, they had a Red Line at the very top there that would usually be used for urgent tasks. Luckily, it was empty.

At the end of their workflow, they also had a set of “Other” tasks – some repetitive or non-development tasks that needed to be done and that would take time from the team. Like meetings, training, or stuff like that.

It didn’t make sense to add those tasks on the main Kanban board, but the team wanted to track them somehow.

Here’s where I want to share a rule that they had.

You see, every person had three sticky notes per day they could distribute on different tasks. they considered each sticky note to be 2-3 hours of their time.

Sometimes “other” tasks would take up some of that, so the person would be limited in the amount of time they could spend on development tasks on the main Kanban board.

Speaking about the rules. They had them right there, explained for everyone to see. 

An important disclaimer I want to give you here.

I’m sharing these rules NOT so you can just copy-and-paste them to your team.

I’m also not saying that these rules are good, or bad.

There are things I don’t agree with, like the sizing, for example.

But I’m sharing this as an example of what this particular team has implemented.

It may give you some insights and new ideas, or maybe just inspiration for your own implementation.

Just know that this is not a one-size-fits-all solution.

So as I mentioned, one of the impressive things for me at least was the fact that this Kanban board was actively used.

We specifically came in for their Daily Kanban.

The team is quite big, but the meeting was finished pretty quickly.

They discussed the progress since their last daily, updated the checklists, moved the tasks around, and the sticky notes representing each team member.

They didn’t just stare at the board and then went back to their seats.

By the end of the meeting, the board looked different.

And you might be saying to yourself – well, that’s great when the whole team can be in the same space, but many people work remotely.

Well, they have a tripod, specifically for people joining on the phone. The phone shows the board, so anyone connecting online can see the changes being done live.

Now I want to share my favorite rule with you. It’s about people being late to the Daily Kanban.

So they have a rule that if you are late to the meeting, you give out a token to the team. And they can use that token at any point in time to ask for a favor.

It can be to go on a coffee run, finish up a menial task, or really anything else.

The fun part is that some people are almost never late, so when it happens, those tokens become pretty much like rare collectibles.

One more interesting thing is that the work tracking doesn’t only happen in the physical board.

The team actually uses Jira too to gather some additional data and also use the reports and other useful metrics collected in the app.

And they have 30 minutes after the Daily Kanban to fill in their updates. Which I found quite a great rule.

It’s not the responsibility of one person to do the updates, but a responsibility of each individual to update their own tasks.

And I believe they have a penalty for not doing it on time… I’m not sure what it is though.

Well, that summarizes this part of the video.

👉 Let’s talk about my coaching approach.

Part 2. My coaching approach to working with the team

And here we go. I was on my way to the team’s meeting.

As I mentioned, we were able to attend their Daily Kanban, so I could observe what’s actually going on.

That’s usually my number one action if I’m just starting to work with a team overall.

And their lobby looks awesome by the way!

I didn’t have a lot of time to really deep dive into their implementation.

So asking the right questions and focusing on the main pain points was key.

My number one question was of course – What's your biggest pain point?

Usually, I would spend some time talking to each team member and observing them for a couple of weeks, and then I would be able to identify the pain points myself.

Why I prefer to observe the team for a couple of weeks and come to my own conclusions is because often when you are in the middle of the process, you don’t realize what the underlying reasons for the challenges are, and it’s easy to fall into fixing the symptoms, and not the problem itself.

But I didn’t have that luxury this time, so I asked the team to identify what’s blocking them right now.

I also needed to have a better understanding of their workflow, and what various notes on their board represented.

This is where I noted that they have checklists attached to each column to verify that the step is actually fully completed.

I was able to inspect the board visually too and make some assumptions that I could immediately validate with the team.

The board seems both very empty and crowded at the same time.

Looking at this board, honestly, I couldn’t say whether there were problems, whether the team was on track, or whether they are being swamped with too much work.

I needed to ask some questions about the tasks they had.

There are lots of things sitting in the Development column, but they are assigned to different people:

So does that mean that the team has too many things in progress? Should they all be working on one project at a time to get it out of the door sooner?

And if not, I don’t see the point in this column at all. Should it be split into multiple columns to track progress?

🔎 If we zoom in on some of the tasks, we see long checklists.

They are being used to track progress, but visually they are not well represented on the board.

I needed to know what level of tasks are represented on the board. So here it seems that multiple tasks are attached to the same project, or the same bigger level task.

But it was unclear on whether the items further down the line were also related to the same project.

As you can see here, I was asking a lot of questions around their workflow, and that of course helped me understand it better.

I was asking about their work in progress limits and how they are used.

Sometimes, just having the team explain their basic ways of working can help them figure out some potential improvements themselves.

Or even show which parts of their setup are overly complicated.

Maybe just the fact that I ask a question about a section of the board can show that it needs changes.

I asked a lot of “Why?” questions, of course.

Like, “Why do you have multiple rows apart from the Red line?”

Or “Why do you use checklists instead of individual sticky notes for each task?”

And of course questions like “How do you know you are on track?” were essential.

Part 3. The summary of the key challenges the team is facing

As any team anywhere else in the world, this team also is facing similar challenges.

There is nothing really new about it, for better or worse.

Here are the things I was able to identify. See if any seem familiar to you too:

External dependencies

One of the key elements of their workflow was validation with the clients and sponsors.

However, they had no way of controlling it since it was people outside of the team responsible for this part.

This could easily get frustrating when a task would get stuck in the column for weeks without a way to move it forward.

New requirements on previously approved projects were often given too late.

Yes, I know, we welcome changing requirements even late in development.

The caveat here is the inspect and adapt – are we adapting our plan?

Because in this case often the original plan would still be in place, but scope would be changed drastically.

That’s ok to change scope, but that change needs to be tracked against deadlines and other goals.

Especially, if these changes may impact other work. Some kind of reprioritization needs to happen then.

Unclear progress

The progress was not very clear, as I mentioned earlier.

While the Kanban board setup was quite impressive, it was very complex and didn’t give easy-to-understand visual information.

🔸 Requirements are not really collected anywhere and the desired end result changes along the way.

Cycle time was too long

Tracking metrics is, of course, needed when we use Kanban.

Or, honestly, any framework or method. Using the right metrics in the right way is essential.

But in this case the Cycle Time was too long to allow the team to respond to change.

It was 77 days! 😶

The reason for that was that the cycle time was calculated on the level of the whole project, not individual tasks.

That also wasn’t helping making the progress visible.

I’m sure we could have dug a bit deeper to find even more, but we had to stop somewhere.

In the end, I was also there to respond to quick questions the team had about small parts of their process.

But one more thing I wanted to note is that even though they had a backlog on one of the walls and they were using Jira, the requirements were not really collected anywhere.

I mean, they were collected, but never really agreed upon. More specifically, the desired end result for the projects wasn’t exactly clear from the start.

That’s why late changes would be often happening as well.

And Part 4. My recommendations for solving some of the challenges.

After getting as much information as I could get in a short period of time, I jumped into solutioning.

Ok, I was definitely not able to offer a ready-to-go solution.

And nobody could, I think, no matter how much time you have.

The most important part was to give some ideas and insights that could bring a potential improvement.

Simplify physical board

One of the key points of a Kanban board is to visualize the work and give easily-accessible information about progress.

The board the way it was used at this point was not providing that insight.

It was way too complicated.

So considering the team was already using Jira, and updating it daily, I thought that it makes sense to have a simple physical board that is easy to follow, easy to update, and very visual.

And at the same time use Jira for details.

If we look at the most basic Kanban board, it has three columns: To do, In progress, Done.

Say we use rows to represent different projects, and then sticky notes for each task.

The checklists of everything that needs to be done is represented with sticky notes.

So every task would move through the three stages.

And so when we look at the board at any point in time, we can see how far we are from getting the whole project done.

We can use dates, like start date and due date to have a better understanding of whether we are still on track.

While simplifying the physical board will help with visualization, the team still needs to have some kind of structure.

That is why another recommendation I made was to use epics and sub-tasks to help with organization.

Basically, it will allow to group work by project and track progress against the bigger goal, rather than just individual tasks.

But also give enough granularity to track the work on a daily basis.

Every project can be marked as an epic in Jira, and under that epic the team would create bigger tasks.

The checklists for those tasks can be represented with sub-tasks.

In Jira it’s easy to get organized in that way.

And using the tool this way will also allow the team to collect additional metrics and use graphs, like the Epic burndown chart or Release burndown, and others.

The use of epics can also help when discussing new requirements with customers.

Since the whole project is tracked in one place, when new work is being added, it can also be tracked.

When new requirements are added, discuss with customers how it impacts the plan and progress, and use graphs.

For example, if we are using a burndown new work will show a spike on the graph.

Or on a burnup it will show on the top line.

So as you can see if we track the ideal line or a line based on our most recent progress, the due date will automatically move further.

If you want to look into this topic a bit more, I recommend looking into my video where I explain various Jira reports.

One more thing that I shared with the team was related to dependencies since it was becoming frustrating for tasks that would get stuck because of other teams.

I suggested to take dependencies out of the process and plan for them as separate tasks.

Right now their board had a column for the Demonstration to clients. Of course most tasks would get stuck there.

Why not have a task called “Demonstration to clients” under the project instead and track it as a task.

Yes, it needs to be completed before the project as a whole can be moved to Done, but it doesn’t impact the overall progress of work.

And that brings us to the end of this video.

I really hope you liked it and you wanted it all the way through.

A few final thoughts to wrap up:

🔵 It doesn’t matter where you are and what language you speak. Kanban is still Kanban. Everyone can speak Kanban.

🔵 I find it fascinating that across the globe we still understand the Agile methods the same way we do it here.

🔵 This coaching opportunity also reminded me that everyone faces similar challenges, no matter the culture. If you work in an organization, you probably are seeing the same things.

🔵 This Kanban system was implemented in this team a long time ago by managers who are no longer working for this company. And this is how you can evaluate whether your approach really works – if people continue to use it even if you are not there. And this team was still using the Kanban system implemented well before they even started this team. Isn’t it interesting?!

Share your thoughts in the comments.

What surprised you while watching this video? What was the biggest insight you took away?

Anyway.

I hope you learned something new today. 😁