We often spend 95% of our time finishing up the last 5% of a task.
The above is a well known fact in software development. In fact it is one of the most annoying things that can happen during the software development life cycle.
During the first phase of a new feature/branch/project apparently we can run through miles of code, implement, test, visualize a great deal of complex behaviors yet when we reach this certain threshold our pace comes to a screeching halt.
Of course there comes a point of time where someone simply runs out of air, where fatigue sets in.
It is very logical to be a bit more picky about certain decisions at the end of a project live cycle. Each line of code, each experience painfully crafted weighs down on the next, so the few final decisions bear an enormous pressure to not screw it up after all the hard work done.
Each time we implement a line of code complexity increases. This only happens after you implement it and sums up during the implementation. At the end of project we have to juggle in our minds all the complex relationships and behaviors that in the beginning were nothing but simple arrows.
Scattering, deviation from a straight trajectory is a very common cause of the 5% rule. Each sub team has a slightly different understanding about the general feature implemented. With time passing this minor differences became bigger and later on, very hard to iron out.
The weight of fighting the above lies with the team leader, scrum master, senior engineer or whoever steps up to the task. It is the fine art of getting things done that I have come to acknowledge in the last years.
The better speced a project is the lower the chances that big decisions have to be made during the last steps of the development.
A project is a dream with a deadline. Even better a project is a dream with many milestones. Well defined points in time break down the bigger picture into smaller well defined chunks. The art here is to be able to break it down into small deliverables that are self contained and complete by themselves.
Constant quality communication
List have helped me a lot during sprints in the past. A simple pencil and paper combination synced between the team members as often as possible. Sure there are more efficient digital ways, but I have come to the conclusion that sometimes analog is the better way to go.