Posted on

Create More Management Transparency

In the agile and lean communities, we talk a lot about transparency.  I see the most product and program success when the various teams create transparency between them, the middle of the continuum. That's the full-product transparency. I see many organizations succeed better when the less the manager knows, the better the team works. And, when there's too little manager-to-team transparency, the efforts become much more difficult or fail. That's because the managers don't explain:

  • Why this product
  • Why focus on these customers
  • Why this product now, as opposed to any of the other work we could do.

The managers don't explain the purpose. So, the managers request transparency about the teams' work. And, the managers don't offer transparency about the purpose. That's not reciprocal transparency.

Posted on

Where I Think “Agile” is Headed — Part Four: What Does “Agile” Mean?

I started this series asking where “Agile” was headed. (I didn't like what I saw at the Agile 2019 conference.) Part One was about the 4 big problems I see. Part Two was why we need managers. Part Three was about how people want a recipe. This part is about what “Agile” or “agile” means.

I understand that people want what they perceive as the value “Agile” will bring them. Let's return to the Manifesto for Agile Software Development, what I call the “Agile Manifesto.”

Posted on

Cost of Delay: Why You Should Care

Want to make money? Work smarter, and faster.

The real problem is this: Why should you care about how much a delayed release costs you? Maybe you have a “sweet spot” in the way you start your projects or release them. “It just takes that long here.” (That’s the sign of a system impediment.)

Now, let’s try to calculate that cost of delay.

Posted on

When Scaling Agile Is Not the Answer

Scaling may seem like the obvious choice, but when it comes to Agile, not so fast.

At the Influential Agile Leader workshop earlier this year, I led a session about scaling, and how it might not be the answer. My experience is that when people use frameworks for larger efforts, they experience these unexpected side effects:

  • The framework actions often require more manager-type people to control the actions of others.
  • The framework creates less throughput, not more.
Agile Scaling Frameworks: An Executive Summary

One of the participants asked, "But what if we have to scale?"

Posted on

Product Planning, Information Persistence, and Product Lifetime

Are you trying to cross the chasm?

I've been thinking a lot about planning recently. Many of my clients want to create long-term plans, based on data with short validity, even for products in a high state of change.

I suspect the first question is how much change do you need in your product, not how good your information is, or how much planning you need.

Posted on

Customers, Internal Delivery, and Trust

Your customers can't take your product more often than once or twice a year. Because the product doesn't need to leave the building, the teams don't release internally. Nor do the teams demo on a regular basis. The teams miss the feedback loops so critical for an Agile approach. Their Agile transformation falls apart.

Rethink Your Definition of Customer

What if we expanded our thinking of "customer"? What if we thought of all these people as customers:

Posted on

Balance Innovation, Commitment, & Feedback Loops, Part 2: Moderate Innovation Products

What if you can plan for a few weeks or even a month or more at a time? You don't need the extremely short feedback cycles (hours to a day) because you're not doing high innovation. You don't need to change what the team does every few days.

You can estimate and commit to maybe a month's work at a time. On the other hand, you need to change your work more often than a two- or three-month period. That much estimation seems like a waste. And the commitment part? You laugh at that. You might like to commit, but you need to change.

Posted on

Balance Innovation, Commitment, and Feedback Loops, Part 1: High Innovation Products

Many of my clients are trying to use short feedback loops in Agile approaches. That desire bumps up against their management's desires for longer commitments. This continuum might help them think through their needs for commitment and innovation.

High Need for Product Innovation and Change

The greater the need for product innovation and change, the shorter the feedback loops need to be. It's not useful for management to ask the team to provide larger commitments, as in “how long will this feature set take?” for at least these reasons: