With Agile Approaches, No Need to “Meet” or “Enforce” Deadlines | Java code geeks


Many of my clients are struggling to meet their deadlines. One of them, Brad, quoted me from Douglas Adams and frowned:

“I like the deadlines. I love the noise they make on the way.

He believed that 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 these deadlines?

Brad said the teams did not appear to be engaged. The company had deadlines because it wanted to respond to market demands. And, the application concerned their governance.

I suspected that I would learn more about engagement with my next questions on business models.

Management models that could cause a team to miss “deadlines”

I find two general buckets of problems for missed deadlines: the way management organizes teams and the “need” for certain actions. (Yes, there are definitely team issues, and that’s a different article.)

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 publish on their own? (Component teams create interdependencies and take much longer to complete the job.)
  • Do you have any shared services teams? (Shared services teams create delays, which would make delays almost impossible.)
  • Does each team focus on one product at a time? (When the teams divide their attention, they need more time to complete each job.)

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 abilities to do the job? Did this team have a common goal?

Single-function “teams”, shared services “teams”, and component “teams” are all work groups. They do not share a common goal and do not have interdependent jobs. They all have to work with other people and teams to deliver.

Cross-functional teams with a common goal can get the job done within a reasonable time frame or understand why they can’t get it done. They tend to get more involved in work and with each other.

Brad replied that no, they were using component teams and shared services teams. Additionally, each component team worked on an unlimited number of products, both development and support, for any given iteration.

These management models create disengagement. People do not have autonomy, control and purpose. These models make it impossible to “meet” a deadline.

Why does Brad want to “enforce” the deadlines? Because of one of their governance measures: the variation of schedules.

The planning gap does not make sense for software products

The schedule gap is supposed to measure progress. However, software product development is not a construction. Creating software is about learning. (See Why do we estimate, anyway?)

Even when we use a non-agile approach, the schedule difference does not make sense. The variance of the schedule assumes that we do not have feedback loops within the project, or that we are not learning anything. Software product development requires feedback loops and learning.

Why did the company want to use the time difference?

  • In the past, the company has had modest success with schedule differences. They hadn’t realized how much teams needed to learn now that products had changed.
  • Because the “teams” couldn’t deliver something small, they didn’t demonstrate very often. Over the months, they stopped giving demonstrations.
  • Because no one saw any demos, the management couldn’t trust the teams to deliver.
  • Managers believed Finance needed a schedule gap.

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

New management choices

Brad started with portfolio management of projects, in order to reduce the overall WIP (Work in Progress) for everyone. An important decision was when to make the big support efforts. Teams still had production support issues, but that was different from the big support efforts “alongside” new product development.

Then they used my Experimental possibility: self-organization of component teams to functionalities teams. (And remotely!) This activity told managers what types of people the company needed to hire to create all the cross-functional teams.

The managers chose to keep the teams together, even though they changed the product the team worked on.

Then, the managers asked the teams to do a demonstration every week instead of measuring the schedule deviations. Even if the functionality has not been fully realized, please demonstrate it. This action changed the way people saw their work. They stopped feeling like they were one features factory to deliver value.

How long should things take?

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

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

“Just like the teams? ” He asked.

Yes, just like the teams.

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

When people saw demos, they stopped asking about irrelevant metrics, such as changing schedules.

The transformation of Brad’s business remains a work in progress. However, they now realize that if they want to reap 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 guide managers and their decisions. Everyone is happier and more productive.



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *