With Agile Approaches, No Need to “Meet” or “Enforce” Deadlines

Several of my clients struggle with their deadlines. One of them, Brad, quoted Douglas Adams to me and frowned:

“I love deadlines. I love the whooshing noise they make as they go by.”

He thought agile approaches would work to “meet” and “enforce” deadlines.

I asked him these questions:

• Do you think people don't want to meet their deadlines?
• Why do you have deadlines?
• Why do you feel the need to enforce those deadlines?

Brad said the teams didn't seem engaged. The company had deadlines because it wanted to meet market demands. And, the enforcement was about their governance.

I suspected I would learn about engagement with my next questions about management patterns.

Management Patterns That Might Cause a Team to Miss “Deadlines”

I find two general buckets of problems for missing deadlines: how management organizes teams and the “need” for certain measures. (Yes, there are certainly team problems, and that's a different post.)

Let's start with how management organizes teams. I asked Brad these questions:

• Do you have product or feature teams that are cross-functional and can release alone?  (Component teams create interdependencies and take much more time to finish work.)
• Do you have any shared services teams? (Shared services teams create delays, which would make deadlines almost impossible.)
• Does each team focus on just one product at a time? (When teams split their focus, they need more time to finish each piece of work.)

Yes, each of these questions focused on one idea: Did managers create cross-functional teams that knew what they had to do and had all the skills and capabilities to do that work? Did that team have a common goal?

Single-function “teams,” shared services “teams,” and component “teams” are all workgroups. They don't share a common goal and they don't have interdependent work. They all need to work with other people and teams to deliver.

Cross-functional teams with a common goal can deliver the work in a reasonable time—or understand why they can't do so. They tend to engage more with the work and each other.

Brad said that no, they used component teams and shared services teams. In addition, each component team worked on any number of products, both development and support, for any given iteration.

These management patterns create disengagement. The people don't have autonomy, mastery, and purpose. These patterns make “meeting” a deadline impossible.

Why does Brad want to “enforce” deadlines? Because of one of their governance measures: schedule variance.

Schedule Variance Does Not Make Sense for Software Products

Schedule variance is supposed to measure progress. However, software product development is not construction. Software creation is all about learning.  (See Why Do We Estimate, Anyway?)

Even when we use a non-agile approach, schedule variance doesn't make sense. Schedule variance assumes we don't have feedback loops inside the project, or that we don't learn anything. Software product development requires feedback loops and learning.

Why did the company want to use schedule variance?

• In the past, the company had modest success with schedule variance. They didn't realize how much the teams needed to learn now that the products had changed.
• Because the “teams” couldn't deliver something small, they didn't demo very often. Over months, they stopped demoing anything.
• Because no one saw any demos, management couldn't trust the teams to deliver.
• The managers thought Finance needed schedule variance.

After several conversations, Brad and his colleagues changed their actions.

New Management Choices

Brad first started with project portfolio management, to reduce the overall WIP (Work in Progress) for everyone. One big decision was when to do large support efforts. The teams still had production support issues, but that was different than large support efforts at the “same” time as new product development.

Then, they used my Experimental Possibility: Self- Organization to from Component Teams to Feature Teams. (And remotely!) That activity told the managers which kinds of people the company needed to hire to create all cross-functional teams.

Managers chose to keep teams together, even if they changed which product the team worked on.

Then, the managers asked the teams to demo something every week instead of measuring schedule variance. Even if the feature wasn't totally done, please demo it. That one action changed how people saw their jobs. They moved from feeling as if they were a feature factory to delivering value.

How Long Should Things Take?

When we started to work together, I asked Brad how long he thought the management changes would take. He asked, “Is this a trick question?”

I laughed and said no. In my experience, the feedback loops and the learning would take longer than he anticipated.

“Just like the teams?” he asked.

Yes, just like the teams.

Brad and his managers struggled for a couple of months with the project portfolio decisions. They struggled longer with the governance issues. However, once they got the portfolio untangled, and let the teams create feature teams, the flow of value increased dramatically.

When people saw demos, they stopped asking about irrelevant measures, such as schedule variance.

Brad's company's transformation remains a work in progress. However, they now realize that if they want the benefits of agility, they don't have to worry about deadlines as much as they need to worry about management actions. (Yes, they read Create Your Successful Agile Project and Practical Ways to Lead an Innovative Organization.)

Deadlines no longer drive the managers and their decisions. Everyone's happier and more productive.

This post was translated to Japanese here: https://www.servantworks.co.jp/2021/with-agile-approaches-no-need-to-meet-or-enforce-deadlines/. Domo arigatou!