Some years ago, I was working with a team developing a new product at a technology company.  The team was concerned that their Time to Market (T2M) was too slow, and they believed that they would be able to improve it by automating their build-and-test process. Automating any manual process is usually a good investment to improve T2M, but I suggested that we should first look at their overall T2M using a very simplified value stream map to understand where they were spending their time. 

Product roadmaps provide a way to understand where a product is headed, but the information provided on most of them doesn’t help to clear the clouds of confusion about whether the product is heading in the right direction

In the Evidence-Based Management framework, we measure opportunities in terms of a concept we call Unrealized Value, which can be thought of as the benefit that would be realized if we could satisfy all of the currently unsatisfied outcomes of our customers.

The most recent evolution of the Evidence-Based Management Guide (EBM) introduced three kinds of goals...

For organizations in the midst of an agile transformation, the question “how do we know if/when we’re agile?” is pressing.

OKRs are a powerful tool for setting and measuring goals, but like all power tools, they can become dangerous in unskilled hands. When used in informed ways, they can improve focus and lift outcomes, but when mishandled, they can increase waste and inflict real damage upon the organizations that adopt them.

Nearly every conversation I have with people who are trying to bring agility to their organizations eventually comes around to the challenge of changing the culture of the organization.

A college roommate of mine retired this week, after a long and successful career. While he's figuring out the next chapter of his life, it caused me to think about whether the notion of a "career" is even relevant in today's world.

I’ve had this ongoing discussion with a few of my colleagues who says that the term “agile leader” is an oxymoron - that the ideal organization is a bunch of Scrum Teams and not much else.

It has been said that the definition of insanity is doing the same thing and expecting different results, and yet we engage in an unconscious fiction of predictability every day. We work in an uncertain world, and our main goal in pursuing agility is to confront the unknown, and in doing so, to master it.

Impact Mapping is a powerful technique that helps teams understand how to link the work that they do with results that their organizations would like them to achieve. We’ve been using this technique for a while in our Scaled Professional Scrum and Professional Scrum Product Owner courses.

According to Forrester Research, 90% of Agile teams use Scrum.[1] One reason for this popularity is that Scrum is a simple framework that promotes transparenc

I have created a little exercise that I like to use to help focus the on things we can change, or at least situations to seek out or avoid, to help focus change efforts. The essence of it is summarized in a picture. I call this the agile affinity model, and the dimensions the key drivers of empiricism.

The truth is, worrying about velocity is a trap: it says “we don’t care where we end up, so long as we get there fast.” That’s just wrong. Teams who measure their velocity but don’t or can’t measure customer outcomes may, quite simply, be driving in the wrong direction.

Organizations who don’t understand why they want to become Agile also often take the wrong path to get there. Agility requires empowering teams and helping them make decisions on their own, learning from their experiences as they go. They must organize themselves, yet they often have Agile practices forced upon them.

I’ve spent a lot of time looking at how organizations are using DevOps to improve their software delivery cycle time, their ability to innovate, and their ability to improve quality.

Agile approaches, including Scrum, are empirical approaches to delivering software and business value.

I’ve been working in software for a long time, and for most of that time I’ve been trying to find better ways of delivering working software.