Why Development Teams Struggle to Deliver on Time, on Budget, or at All

Why Development Teams Struggle to Deliver on Time, on Budget, or at All
7pace.com

Generally that results in one of two things:

* Product delivered on-time with massive technical debt.

* Product delivered late with massive technical debt.

Frankly I don't know if adding front-line engineers to the deadline decisions is going to make the issue better or worse, but fundamentally having non-technical or formerly-technical people defining deadlines definitely doesn't work.

And then came the Assumptions.

And the Assumptions were without form.

And darkness was upon the face of the Workers.

And they spoke among themselves, saying, "It is a crock of shit, and it stinketh."

And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof."

And the Supervisors went unto their Managers, saying, "It is a container of excrement, and it is very strong, such that none may abide by it."

And the Managers went unto their Directors, saying, "It is a vessel of fertiliser, and none may abide its strength."

And the Directors spoke amongst themselves, saying one to another, "It contains that which aids plant growth, and it is very strong."

And the Directors then went onto the Vice Presidents, saying unto them, "It promotes growth and is very powerful."

And the Vice Presidents went unto the President, saying unto him, "This new plan will actively promote the growth and vigour of the company; with powerful effects."

And the President looked upon the Plan, and saw that it was good.

And the Plan became Policy.

This is How Shit Happens.

1. Poor engineering planning. The way to do this well is to break down a feature until they’re at about half-day sizes tasks. Identify any obvious risks or ambiguities with the technical approach and communicate them to Product and figure out how to de-risk them. Communicate costs to Product so PMs can make cost/benefit trade offs (eg “if we built it the way you specced it it’ll take two weeks. But if you make these trade offs it’ll take two days.” As a Product Manager I might not want the feature if it costs two weeks but do if it costs less than 5 days. Without costing the features in dev days I can’t makr this trade off).

2. Failure to make trade offs that drive towards shipping software. The way you ship is by declaring it’s done, even when it’s not really done. When code is being written unexpected issues always arise. It’s Product’s job to make hard trade offs that drive towards shipping. Eg “that’s an edge case bug, let’s punt it to v2” Or “let’s cut that nice to have feature and squash the showstopper bugs and ship”.

People bring up impossible deadlines set by management. In my experience most deadlines are movable and a strong PM/Eng team can convince management to push a deadline back. And if a deadline can’t be moved, it’s all the more important to know how much features will cost and make hard trade offs to get the product out the door.

I've worked with Engineering VP's/CTO's that are pressured by deadlines and promise unrealistic features. The key element needed in this is a 'leader' that can push back and manage expectations.