This week we talked about ambushing the problem of too much WIP and exposing dependencies.
Ambush the Ringleader
- We spent a fair amount of discussion around the value of swimlanes on a kanban board. All of us have used the typical Scrum board which has swimlanes for each person. How valuable is it to know who’s working on what? It seems like the vertical columns that define the state of work are more useful.
- None of us have worked in environments where states had WIP limits. This led to further discussion about what it means to have WIP limits. Isn’t an individual’s WIP limit one because you can’t physically work on more than one task at a time?
- When you’re blocked, your individual WIP limit goes to zero. The idea is to finish one unit of work before starting another. Having a “Blocked” vertical swimlane/state is useful because it shows how many things are stuck, which in turn leads to, “Why are so many things blocked?”
- Tasks have an inherent WIP limit of one. Stories could have a higher WIP limit. For example, if Houston is doing the backend logic for two stories and Geoff is doing the UI work for those stories, technically both stories could be in progress.
- Interruptions are inevitable. We all agreed with the author about when we have to move a blocked task to the back burner: “Like rotten fruit, knowledge decays faster than we’d like.”
- When implementing change, start with small, positive changes. Changing too many things at once is a tough pill to swallow.
- Aside: The author calls interruptions “silver bullets,” which doesn’t mean what she thinks it means.
- Jameson brought up an astute point about interruptions: They can fly in the face of what Agile is all about. Change is inevitable; we can’t be blind to it. If we say “no” to all business requests during a sprint, is that what’s best? Houston suggested turning those requests into tickets/stories, which triggers a backlog grooming. Geoff said if there are many such tickets, why is that happening? Are things so chaotic that you can’t finish your sprint? Is this a political/personal problem, or is your business niche so unpredictable?
- How do you handle when only one person knows how to do certain types of work? We all believed the ideal answer is to slow down, then invest in cross-training others so that you can move fast later.
Expose Dependencies
- The book mentioned a common type of time theft comes when you have many teams working on different parts of one big system.
- We pondered about one of the diagrams in the book. (Here’s an example of a dependency matrix from Wikipedia). The matrix isn’t symmetric because the dependencies are directional: How many times thing A depends on thing B could be different than how many times B depends on A.
- The dependency matrix is likely only useful at the macro level, as the micro level would change quickly. However, there are tools like Visual Studio or NDepend (for .NET) that help you visualize this based on the codebase.
- The book makes a distinction between product and project. A project is the whole thing you’re rolling out and requires a considerable amount of coordination. The product is what the team focuses on to deliver value, so you keep domain knowledge together.
- If you have cross-team dependencies, break the stories up for each team and mark them as related in your work-item tracker.