When talking about agile practices, the distinction between projects and products often comes up. The idea is that the limited lifespan of projects tends to be pushed onto the delivery team, which leads to the team being assembled at the onset and dismantled when the project completes. Agile practitioners advocate for a product view, where teams are dedicated to a specific product and deliver incremental value at a regular cadence, across initiative lifespans. This usually works really well, and I too favour a similar way of working in most cases. However, I have recently seen various examples of this idea being misinterpreted, which creates a situation in which teams struggle, largely due to their setup.
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...
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...
“Whenever there is a product for a customer, there is a value stream.
-John Shook and Mark Rother, Learning to See”
Creating more value for customers is a core business strategy. With more technologies being developed, companies have been optimizing their software delivery to get the best value out of their products or services. Instead of focusing on individual functions, companies are now developing an interest in the end-to-end value chain. Software development is no longer just the business of IT departments. Company leaders and management are taking an active role in making sure that the software delivery process is driving value to the business. In a way, every organization has become a software company.
Unfortunately, even after investing considerable time and resources on IT transformations, companies still experience misalignment in business vision, strategies, and goals. While they may have implemented new ways of working, such as Agile and DevOps, there is often a disconnect bet...
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.
The Greek philosopher Heraclitus was onto something when he said many years ago that
“Change is the only constant”
A saying as true today as it was for Heraclitus in Ancient Greece.
Today, businesses are impacted by change. Competitors introduce new capabilities or services, customers' loyalty shifts from brands towards value propositions, and new and exciting players disrupt the market altogether.
Introducing organizational change is a tricky business, especially when it involves new technology. Even seemingly innocuous changes to technology can have a far-reaching impact on your organization, disrupting the ways you work. Your initial vision of a smooth implementation, rapid adoption, and a high return on investment is easy to say, not so easy to achieve. For example, it is widely discussed that 70% of transformations fail.