Waterfall Development
Back in the days of waterfall development, big huge up front planning meetings mapped a year long (or longer) development cycles. But how is it possible to estimate effort when the ones doing the estimation are not the developers? The answer was, "Waterfall doesn't work" let's move to Agile.
Agile
Agile prescribed the short two week iteration, along with planning poker by the developers (for more accurate effort estimates). Closer to reality, for sure; by revealing impediments early. But ultimately the quarterly planning by upper management precluded any impediments. The needs of the business always trumped everything else.
Continuous Delivery
Continuous delivery was then prescribed, it said "We'll delivery continuously, as we know we'll never have the entire thing finished".
Continuous delivery allowed the development teams to do the best they could within the constraints allowed. Constraints such as bad development environments, lack of product knowledge, poorly written code, and perhaps most of all, too much complexity. These constraints popped up all the time, at the worst time contributing to missed expectations.
A Solution
So what's a solution to the "Quarterly Planning Expectations versus the "In-the-trenches" reality of deliverables?" Two key points come to mind:
1) Developers must work smarter by creating Small Reusable Parts all consolidated into their "parts toolkit". These "parts" must be easy to use (plenty of comments or examples contained within the part itself).
2) Upper Management needs to to focus on reported Impediments. This means that all Impediments stop progress. The fallout being pervasive with continual context switches, trying this, trying that, lack of direction, discovery of poor intra-communication processes etc. Total chaos for sure.
The worst thing Upper Management can do, is to not acknowledge the impact on deliverables based on Impediments. By doing this; the developer, always becomes the reason for missed due dates.
Try these two things and see if it helps!
JWP2019
Top comments (2)
After a lot of experience I know this can't happen and won't ever happen but if management decided we are releasing software in 3 months and that timeframe is non-negotiable then what should happen is they pitch what they want to the team and the developers say what they could complete in that time frame with the resources allocated currently. Then they could address whether adding more resources would help or if they need to sacrifice features. Really management just needs to understand the projects working triangle. The rule is you can only have 2 of these 3 points on the triangle while maintaining quality. So what is it going to be management,are you flexing on time, getting more resources (if that would help), or compromising on scope because sacrifices on quality should never be on the table for discussion.
So true.