I started this series by sharing my status of too much WIP (Work in Progress). My WIP was making me slightly crazed and I explained how I worked to reduce it.
In case you're wondering, here's my current status:
- 3 presentations still on the list (I completed 2, including the one I recorded).
- The online workshop videos are complete. When Teachable settles down, I can start to upload.
- A total of about 1500 words on the book plus one image. I'm pleased with my progress.
- No fiction, no columns.
- The book distributor work is complete
- I completed my other blogging and fiction newsletter.
I still have a bunch of writing plus those three presentations remaining on my list. However, it's just noon on Friday as I write this. I have time to make even more progress before the weekend.
While you might have found my approach interesting, you might worry—can you do this for you, your team, and your organization?
Yes.
Let's start with WIP because if your team is anything like my clients, your current WIP is too high. And your planned WIP is even higher.
Reduce Team WIP with Collaboration
In Build Team Resilience: Work Together (Part 1), I said that collaboration was not the same as cooperation. If people work primarily alone, and ask others for code review, they cooperate. However, everything takes longer. (See the value stream map image.)
However, if people collaborate with pairing, swarming, or mobbing, they work in flow efficiency. By default, they work on fewer items at one time.
The more a team collaborates, the higher its throughput. The higher the throughput, the less WIP they tend to have, because they're finishing faster. (See Shorten Team Feedback Loops with These Three Questions to Increase Throughput or any of the Little's Law posts to understand why.) When they finish faster, they have less pressure to do “more.”
Once the team realizes they can manage their WIP, they can start to use continuous flow (even if they “need” to plan in iterations).
Work in Continuous Flow
When a team only works on one item at a time, they only have to focus on that one thing. They can:
- Create interim deliverables.
- Ask for feedback every time they have another deliverable.
- Keep everything clean.
No one has to remember anything at all because the team focuses on this one item. (I'll talk about looking ahead and planning lower in this post.)
If you have a larger team, sure, have two things. But make sure the team's WIP does not exceed the team's capacity to finish one thing every day or so.
If you can't right-size yet, the team needs to collaborate. That collaboration means they will learn together and learn how to right-size organically.
Work to Learn and Learn to Work Better
I probably didn't mention my learning loops in these posts, because they're so ingrained. Every time I finish something, I mentally note how long it took. That's why I know my cycle time for writing fiction and nonfiction. And how long it takes me to create a presentation. I also know my cycle times to develop workshops and video them.
I have learned these times as I practice and deliver.
You can, too.
If you're not doing little kaizens or retros every single time you deliver anything, it's time. Take 5-10 minutes. Note your cycle time for this thing. (No judgment, just write it down.) You can build your “library” of cycle times for work you might repeat. And for brand new work? Understanding your cycle time helps you right-size the work for the next time.
Collaboration and Learning Creates Ease
All this collaboration and learning together means the team shares its product development. That sharing creates ease, aside from making it easier for the team to succeed.
Notice how as soon as the team collaborates, you probably don't have to worry much about your personal WIP. That's because you share your WIP with the rest of the team. Unless you're a manager.
Reduce WIP Across the Organization
One of the reasons planning takes so long is that managers multitask. If you're a manager, ask your cohort to work with you and decide—for now—on what's most important for the organization. Have a workshop to decide. (Don't call it a meeting. You're workshopping.) Decide how long this decision can last.
Tell the team(s) who need your decisions. (This is why management decision cycle time matters.)
Take the next decision on your list and do the same thing.
You will need a management cohort to do this. If you're a product leader, you need a product value team.
No one can work alone for product development and know that they will make great decisions. So reduce the pressure on you and work with other people.
What about all those freaking plans? Time to clean.
Reduce Your Backlogs
If you have anything in your backlog older than three months and no one is currently working on it, archive it. Same for your portfolio. Any of those lists of things that only seem to grow longer every day. See Clean Your Backlogs and the Day 3 post.
Everyone sags under the weight of all that pre-planned work. You're probably not going to need it—not in its current incarnation. And I'm sure you will only need some of it, not all of it. This is the difference between how much and how little thinking.
There's more here, but that will start a new series and I don't want to write that now.
Instead, scale the thinking so you can reduce WIP, increase throughput, decrease cycle time, all to create more ease.
Use Little's Law to Help Think at “Scale”
I knew about the effects of multitasking early in my career. That's why I wrote about multitasking, first in Manage It, and then in Manage Your Project Portfolio. I didn't know about Little's Law.
It took a new client and some measurements for me to see the effects of large WIP. (See Little’s Law for Any Kind of Product Development: How to Learn How Long Your Work Will Take.)
If you want to “scale” your agility, ask yourself these questions:
- How can we collaborate at all levels?
- Will that collaboration shorten our feedback cycles and reduce WIP? If not, what will?
- What effect does aging have on our work?
Remember my secret sauce from yesterday's post:
- Clarify what done means, preferably for an interim deliverable, an outcome, so you can learn from that outcome.
- Focus to finish that outcome. (I should have added, “Make that outcome clean.”
- Make small progress so you want to make more small progress.
I've shown you what I do at the individual and team levels. You can do that, too.
If your managers scale these ideas, they can also become more agile. That means you will all create ease in your work.
I'm done now, so I can return to my WIP. Hehehe.
The series:
- How I Manage My Product Development: Ease with Continuous Flow (Day 1)
- How Cycle Time and Cost of Delay Makes Product Development Decisions Easier (Day 2)
- Easier Product Development Decisions and Why Backlogs Might Slow You Down (Day 3)
- Focus on One Internal Deliverable Allows Me to Work Down My WIP (Day 4)
- How You Can Find More Ease in Your Product Development (Day 5)