How well do you know Kanban? What does managing WIP mean?

Dive in 🤿 and let's 💬.

🧵 Intro to Personal Kanban

If you've never heard of Kanban, Wikipedia https://en.m.wikipedia.org/wiki/Kanban_(development) provides a good overview.

I use Kanban because...

• It scales to any size project.
• It’s a framework and can be incorporated into existing processes.
• It has one rule; limit work in progress (WIP).


My personal Kanban setup is simple. I put tasks (issues) into three columns; backlog, in progress and waiting. An issue is a simple unit of work. If an issue has multiple parts then consider it as multiple issues. It will make managing WIP more effective.


Backlog

Every issue begins life on the backlog for grooming. I use these questions to groom an issue;

• How important is this issue?
• Can this issue be broken into more minor issues?
• Who is the best person to work on the issue?
• What is this issue dependent on?


How important is the issue?

The 1st line of defence for your time is whether an issue is deserving of it. Progress gets cluttered with issues that are not important. If an issue is not important, trash it. If it’s actually important it will find its way back to you someday.


Can this issue be broken into more minor issues?

If you can divide an issue into smaller issues you have options. Consider an issue that takes 16 hours of work broken into 8 issues of 2 hours. You could make 2 - 4 hours of progress per day with a buffer for other work.


Who is the best person to work on the issue?

Are you the best person for the issue? If you break an issue into smaller issues perhaps it can be delegated to one or more people. This frees you to work on another issue and increases velocity for getting to what’s next.


What is this issue dependent on?

Often there is a sequence to completing an issue depending on other issues being done first. An issue can be “blocked by” or “blocking” another issue.

In Progress

Kanban has one rule; manage work in progress (WIP). The best practice is to limit WIP to 3 issues. This maintains focus and flexibility for multiple priorities. An issue remains WIP until it is complete or requires action from a 3rd party.

Waiting

When an issue requires approval or input from someone I pull it into my “Waiting” column (aka follow-up). While it's waiting a new issue can be pulled into WIP or not. Treat “waiting”, the same as WIP. Don't let issues stall waiting for feedback.

Why is there no done column?

Kanban is flexible for your workflow. My approach is keeping my board lean and clean. When I close an issue I enjoy removing it immediately. My suggestion is; that you do you.


Intro to Personal Kanban

Are you constantly switching applications and allowing a barrage of messages to take over your project? This is what Cal Newport calls the "hyperactive hive mindset." 🧵https://www.bbc.com/worklife/article/20190715-how-to-escape-the-hyperactive-hivemind-of-modern-work

It is a serious risk to a project's success. The solution? Build the project workflow into a "single source of truth" #SSOT. https://en.wikipedia.org/wiki/Single_source_of_truth

By using a content management system like @NotionHQ you can bring all the critical elements together into one #Agile #SSOT. Let's consider a few of the items that need to be included;

Kanban boards are a feature of Notion databases. Many of my projects use an adapted version of the Lean Lifecycle from @Disc_Agile. Since Notion gives you "view" and "sync" options for the same database you can provide multiple perspectives on the same information.

Chat needs to be in context and always in one place. Using comments in Notion enables chat for specific tasks or other aspects of the projects. All in the same workspace. #SSOT.

⚠️ Avoid the trap of multiple chat apps. I've been brought into projects that were spread across @telegram @WhatsApp @SlackHQ @gmail and others. This just results in chaos and confusion.

Stakeholder participation must also be managed. Notion allows you to share content outside your organization using "guest" access. This unified commenting in the context of the work reduces back and forth and provides clarity. Reducing misunderstandings about feedback.

The #SSOT approach is ideal for documentation. As you're building, the documentation is being developed simultaneously. Then you have two options to share it either using the built-in @NotionHQ feature or a 3rd party app like @super_.

Finally when you just can't find what you are looking for there is always a Command-K universal search. 

What are your thoughts on #SSOT for #projectmanagement or other use cases?

Building a Single Source of Truth

Looking for a simple way to kick off your next project? This three-step framework might help. 🧵

In my world, every task is a project. Small tasks are micro projects. Bigger tasks are broken into a project or a collection of projects. Heck, my life is broken into projects.

Personal projects around the house, health and relationships. Sometimes, my young adult children's projects become my projects. Then there are work projects.

Being effective at delivering work projects is a critical job skill today. The Boomer generation’s work was organized into departments. Projects were managed within the department and "presented" to other departments.

Today's work models are skill focused. Project teams form a "temporary" cross-functional department and deliver an objective. Individuals on the team have multiple skill sets and domain expertise. The team might be co-located or spread out across multiple time zones.

Every project begins with an objective. Watch the video below to introduce you to our use case.


https://twitter.com/wowinteresting8/status/1558661345863733250

In this use case, the objective is getting the stone from point A to B. How did they arrive at this solution? Let's try three simple questions.

1: What is known?

Consider the facts they knew to be true about the task. Facts can be backed up with clear evidence. If it can be debated it’s an opinion. A few examples for the use case;

• The stone is too heavy for one person to lift.

• Point B is downhill.

• Gravity is a real thing.

• Point B is not a straight line.

• We have a saw, hammer, chisel, rope, two wheels and cord.


2: What can we test?

A test eliminates possibilities in the shortest amount of time. Carrying the rock was likely eliminated from previous experience. This is why it was considered a "fact" above. It had been previously tested and the result was a back injury.

Another fact from previous experience is the leverage a wheelbarrow brings to the problem. When tested it is learned that maneuvering a wheelbarrow, under load and down a slope is onerous and back-breaking, but, it works, and many would stop there.

3: What can we improve?

Let's assume we test the wheelbarrow solution and are successful. However, there are more observations;

• The load is difficult to control.

• The wheels slide on the loose ground instead of rolling.

• It's slow.

There will always be room for incremental improvements. Sliding on separate footboards with the load was likely an incremental improvement. It also removed the need for the operator to "lift", sped up the work and allowed the "driver" to shift weight to assist with steering.

The Point 👇🏻

If you're looking for a way to initiate projects faster this simple framework is a good place to start. It doesn't require any fancy tools except paper, markers and a saw. 😉

A Simple Framework for Project Kick-Offs

Do you find that every time you open a new browser tab you get distracted?  I do! It's like a squirrel 🐿️ jumping in front of me and I'm down for the chase. Here are a few tips I find useful for staying on track #projecttip



First, block out time to work on big things that do not require context switching. Coding, writing, experiments and carving 🐿️ out of wood should not be interrupted. The tips below are for when you are in the s#&t and fighting to stay alive.

Have a small notepad next to your keyboard. Jot the items you are working on down. I use a mechanical pencil, Rhodia No 12 lined pad and a memo spike. Spiking a note feels so much better than just crossing it off.


Why do I use the notepad? It's fast and anchors me to what I was doing. For example, maybe I'm responding to an issue on Slack. I switch to email to get some details I need. There are ten new emails and a 🐿️ get's my attention. 

I have a choice. Chase the squirrel or make a quick note to come back to it. If I decide to chase the fury creature then when I'm exhausted I check the notepad for what the 😈 I was doing when I got into this mess. 

If... and it's a big if... I manage to be disciplined the other choice is to note the new squirrel on the pad. When I'm done with the first 🐿️ look at the pad and decide which squirrel to chase next. 

At the end of the day, I make some decisions about what's left on the paper; trash or transfer. If it really is not important then trash it. Don't let it clutter up your mind. If it's relevant, important, or should be delegated then I transfer to @WorkFlowy. For another day.


Staying on Track Despite 🐿️s

"However, it could also reflect a lack of work-life boundaries within remote teams. According to Microsoft’s research manager, people have 250% more meetings every day than they did pre-pandemic." via @MorningBrew


I've been reflecting more on this tweet and felt it deserved a thread. So here goes...

IMO if your day is > 25% internal #meetings then you're getting it wrong. One recent example is a client with a department of ten employees. They were spending at least 20% of their day in department meetings. Often with all of them in attendance.


Another 30% of their day was spent on intra-departmental meetings. Some napkin math... 200 hours per week in meetings. Assume a $50 per hour average salary that $520,000 in meeting time per year. 



That is enough to make most CFOs cringe. When you roll up that time it still doesn't reflect the intangible related costs.

- context switching - getting back to work post-meeting is time-consuming. "What did I miss?" drags the best into chasing squirrels 🐿 in the inbox. 

- TMI - most meetings are longer than they should be. The result is a lack of clarity on action items. 

- Exhaustion - many are just mentally exhausted after an hour plus of meetings. Not the ideal state to get quality work done. 

To convert some of this time back into deep work we did a few things.

1. Identified 3 pieces of important work requiring focus and delivery in the next two weeks.

2. Created 3 teams. One for each piece of work.

3. Set up rituals to manage the workflow.

The rituals included;

1. Daily team 15-minute synchronous stand-up to discuss blockers.

2. Weekly 1 hour cross-team meeting to discuss progress and ideas for blockers. 

3. Planned the issues in @linear for an #agile delivery process. I will discuss @linear more in another 🧵

The results. 

- 20 hours of meetings per week (instead of 200).

- Issues all delivered and  new work added. 

- Team members reported improved wellbeing and deeper states of flow. 

You can read the unrolled version of this thread here: https://typefully.com/the_agilepm/6AbRYEi