I’ve worked with several managers and team leaders over the past few weeks as everyone is suddenly remote. Every single person in a leadership position struggles with (agile) team transparency. These leaders think the team members work alone. (I think they’re correct.) The leaders worry that the team won’t finish the team’s work. (Correct again.) […]
I spoke with an agile coach whose team works in flow, similar to this board. They don’t use iterations—they plan on demand. The column on the left, “Stories to Workshop” is their backlog refinement column. Recently, the team decided they need “minimum” WIP (work in progress) limits. Especially on the Workshop column. Why? Their product
Many of my clients use an iteration-based agile approach. And, they have these problems: They “push” too much into an iteration. They use velocity, not cycle time to estimate. They rarely finish everything before the iteration ends. They have to manage extra work—work they had not estimated—in the form of an emergency or production support.
Many new-to-agile teams use some form of iteration-based agile approach. Often, in the form of Scrum. Back in Time You Spend in Agile Meetings (near the bottom of the post), I enumerated all the possible meetings. I suggested the team review its WIP limits and think about limiting the WIP for the entire team. When the
As I’m writing the agile project management book, I’m explaining how agile creates and manages WIP (Work in Progress) Limits. Iteration-based agile manages WIP by estimating what you can do in an iteration. You might count points. Or, you use my preference, which is to count the (small) stories. If you use flow-based approaches, you use kanban.
If you are wondering, “What do I do with the work I said no to?” here’s the answer. Use a parking lot. This is the image from Manage Your Project Portfolio. I recommend just four columns: the project name, the date you put the project on the list, any notes about value, and any other
My most recent post about how to Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban. I use paper. Here’s why I don’t use a tool: I am too likely to put too much into a tool.
Most people I know—even the people supposedly using agile approaches—have too much work to do. You have project work. In addition, you have support work, formal for customer support or sales, and informal for your colleagues. Let’s not forget the reports to write or file, time cards to fill out, or other periodic events. You
Matthias Bohlen interviewed me as part of the preparation for the OOP conference. We spoke on a wide range of topics, not just my talk which is “Six Behaviors to Consider When Hiring for an Agile Team.” We spoke briefly about program management, which is why I’m leading my influence tutorial. Hear the entire podcast