Thank you for subscribing! An email is being sent to the address you provided – please check your inbox and follow the instructions. In the meanwhile – here are some of other blog posts you might like:
Patterns for getting to a lower WIP level in a system – The Freeze, No New Work, Limit Later, and some Mashups…
Some of us have the luxury of designing processes for greenfield systems meaning there is no history/legacy to deal with. Typically though, we are dealing with Brownfield/Legacy systems – This usually means there is some work in the system already, there are outstanding commitments, and some existing queues between steps in our processes. I’m working
Background I recently had a short twitter chat with Catherine Swetel and Steven Holt about the relation between TOC Critical Chain and Kanban. This post will try to sum up my thoughts in a way that is a little bit more persistent, as well as add a bit more color and depth that is not
Comment: We’re reposting here a classic article from the archives of Yuval’s personal blog. I’ve been using a visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from “The Little Prince”.
“There’s no predictability/commitment in Agile” Over the years I’ve heard my share of these kinds of statements from various levels of executives: “When my guys run a product development release I really want to know what I will get at the end so I can make business plans accordingly” “In the old days when we
We’ve all seen it. It’s quite an elaborate show with Scrum Masters, Sprint Planning, Daily Standups, Secret handshakes, a lot of artifacts, ceremonies, roles. The recent “broadway”-level productions include bigger pictures, more roles, artifacts. It is like visiting the city set in that classic Universal Studio ride. Excellent production value but not really a working city.
It is so great to have some slack time, as you can let your mind get off a bit from your own coaching activities and learn from others. It is also great as sooner or later you will connect the dots back to implement those insights and even write a post on it 🙂 At
These days, it seems that scaling Agile is all the rage. But while Agile might be the most efficient way to get a product to market, scaling it is a road filled with potholes and landmines so you should start by asking yourself if you even need to scale Agile and then if that’s the
Don Reinerstern in his book “The Principles of Product Development Flow” writes about the importance of having an economic view when making decisions. This is as usually we are developing products to improve our financial standing (and even if it is not for “making money” but rather for nobler reasons, still there is the economic
You can read in many places (for example here or in Don Reinersten’s Book The Principles of Product Development Flow) that when you avoid over utilization (that is, use less than 100% capacity) a system (like a road or a scrum team) that handles items with variation (like cars or stories for software) you get
A good way to improve how a team works together is to try to run experiments for collaboration. We’ve listed here a set of experiments you may want to try, depending on where your team is in the journey for better teamwork. Each section has a description, a goal for improvement and then the set