It’s one of those words that come back over and over again in context of modern delivery approaches and organizational structures. The word seems common enough to mean approximately the same in people’s minds, however I have found that it is often confused for something else. According to Merriamm-Webster, autonomy is the quality or state of being self-governing. This distinguishes it from the term empowerment, which is the state of being empowered to do something. In other words, autonomy is an internal property - it comes from within -, while empowerment comes from someone’s approval.

Autonomous teams make their own decisions, they do it based on their objectives and all the relevant information they have available about the world around them. Empowered teams also are told to do exactly that. However, the scope of their decision making power - sometimes explicit, more often implicit - limits their autonomy significantly and can even shrink should a decision be made that does not align...

Whenever the weather allows for it, we like to eat outside. At dinner time in our little courtyard in the city of Toronto, mother nature treated us to a beautiful scene. A few days later it turned into an invaluable lesson...

Two doves and a chick

A mourning dove landed on the fence, looking us straight in the eye. "What a wonderful sight," I thought, "I bet it's eyeing something on our plate." Without breaking the line of sight, the dove flew over to the side of the deck, even closer, testing the boundaries of its comfort zone.

"Roocoo! Roocoo!" A few minutes later mommy dove arrives, a little chick trailing inches behind her. The family reunited, they waggled to an open space a bit further away, while we watched the scene unfold at a safe distance. By now we realized that daddy had scouted the environment, checking our reactions to his proximity. He must have considered us safe, the little one would not be harmed.

To our surprise, the adults took off, leaving the little one alone. Stunne...

In previous posts, we discussed what you can learn about your team from tracking a minimum of data. We introduced throughput as the most meaningful metric you can get from only the completion time of a work item. In a subsequent post, we explained how you can calculate cycle time and work in progress by tracking the start time of a work item. In this post, we focus solely on how to calculate failure demand and what it tells you about the true delivery capacity of your team.

Continuous improvement is at the heart of any agile approach. But where do we start? And how can we know that our improvement initiatives are moving the needle? This blog post expands on the ideas from what throughput can tell you about your team and provides some additional thoughts to help you truly embrace the following principle from the agile manifesto:

Well-designed metrics provide your team with insight into where to focus and look for improvement opportunities. They also provide you with a baseline, a measuring stick to assess any improvements.

In a previous post, I focused on what we can learn from a metric as simple as throughput. Here we take it a step further.

As health specialists and governments encourage employees to work from home en masse, many employers start fearing the impact on their teams’ productivity. After all, the agile manifesto states as one of its principles:

Are we doomed to return to less agile ways of working? Will we see productivity plummet? Will we see new value being released only ever so often?

Online teams are less effective than collocated teams

Let’s first start with this breaking down this statement.

The main difference between online (or remote) and collocated teams is the way in which they communicate. Collocated teams benefit from what Alistair Cockburn calls osmotic communication. You could explain it as transfer of information and knowledge by virtue of being in physical proximity with your team, where all work is done, where all frustrations are voiced and all intentional and unintenti...

Last Friday I presented a session on outcome based metrics at the Lean Agile Network meetup in Toronto. Based on the popularity of the session and the questions which we didn’t have the time to address, the topic is clearly on many people’s mind. More to come on metrics in future posts, but for now we’ll focus on what you can learn from the simplest metric of them all: throughput.