Delayed Features and their cascading effects

Overpromise and Underdeliver . Its meant to give out the message "More efficient and quicker deliveries". More efficient in terms of requirements, planning, development, testing and deployment. Startups, big orgs which have high performing small functional teams where inter team interactions are a pain usually fail to crack this code.

Lets say there are Four features that a team plans to deliver over say, next Four weeks. At the end of week two, lets say one feature is in an alarming position w.r.t. its deadline. Now the following effects are usually observed :

1. Team shifts its focus to the feature whose deadline is under threat.
2. The effort on other three features is compromised as a result.

Yes, the above scenario is the right scenario to opt for in a lot of situations. If that one feature happens to be a feature because of which your product is hanging by a thread, its neccessary to take that step.

The above is the scenario where all four of your releases got delayed, maybe not by huge amount, but they got delayed nevertheless. This is the cascading effect of that one feature which delayed all other feature releases. However, if this approach becomes a part of the working culture of the team, it starts to have negative impacts in the future. A lot of people missing their targets is not a better situation than few missing targets and others getting things done on time. A target missed is a target missed, even if its by a day or a week. It brings down high performers to the levels of average and low performers.

A second approach could have been let the first feature take its own time but make sure to not slack on the other three features. Infact, a lot of teams take short term learnings and try to apply it to other ongoing featueres. A lot of times, you will be getting most of your features on time.

Why is it important to shoot for on time releases?

1. Helps with the confidence and morale of the rest of the team (which got the other 3 features done on time)
2. Helps to figure out missing pieces during every sprint planning.
3. Helps to boil down to less scenarios (that one delayed feature in the above case) to focus on in the coming sprints (Maybe increase a week for any feature involving 3 teams).
4. Enhances the ability of the team to be able to not let one miss affect other plans.
5. Helps individuals to improve their working style. Maybe one developer was working on two features and ended up picking them up in the wrong order.
6. Improves ticket/JIRA tracking from next time. Maybe give two more story points for testing from next time if people overshot their testing duration.

Writing fast or more code is not the solution to faster releases. An hour of brainstorming, planning and design could save a lot of hours of code and anxiety later on.