What do you think will happen in a project if there are good developers, QA, leads? Will it be successful?
The majority of you may say yes, why not? But what If I told you there’s a 50–50 chance that it may or may not be successful?
1. Requirement changes
The first thing that we must accept is the fact that the developers coding for the project are human beings and we get tired and frustrated.
And we have a personal life outside the office hours too
Yes, we want to do a good job, but if the manager or BA keeps on changing the requirement now and then and keeps on labeling every change request as urgent, must do, MVP requirement.
The project will fail not because it doesn’t have good developers, but because these managers and BA keep on forgetting the basics of project management.
Solution: If your team has such amazing people who love to make changes in the requirement, then respectfully ask them to put these new requirements in the backlog, if you don’t do this then such requirements will just keep on coming and soon you will be looking at a mountain of requirements that you didn’t plan for but now you have to deliver everything next week.
2. Unrealistic goals
Before start of the next sprint let’s say the project manager and BA meet with the team to discuss what stories will be completed in the current sprint basically sprint planning.
In this meeting, it’s the role of the senior/tech lead to making sure that the amount of stories that are being added is something that the team can achieve.
One of the key factors in this meeting would be for the senior/lead to identify spike stories (basically the one’s which would need some research or some proofing)
Setting unrealistic goals can cause project failure, so set realistic expectations and try to push back because if not then my friend it will be you working for 14–15 hours just to please the management and get that march hike.
Family, health and mental peace should always come first. It makes no sense to take more stories than you can handle.
3. Cutting down estimates
Yes I know, we all want to see the project go out to production asap, and do some chest-thumping and back-patting but there’s something called quality which requires patience.
One of the most common practices I have seen is that when a developer provides an estimate then some wonderful managers cut down a few weeks or days in the estimate and the reason for that is
“Developers do whatever you want to, burn the midnight oil, work on weekends if you may but we have to deliver this 100 hours work in 40 hours”
If this is the motivation behind the estimate chopping then perhaps I think the manager should learn coding to work with the development team
Provide a helping hand by writing the code and test cases and enlighten us with their great wisdom showing the path and technique on how 100 hours of work can be done in 40 hours.
Solution: Here the lead or the senior has to push back, they need to say NO to such demands which will not only ruin the project but also ruin the code quality and create unwanted pressure on the team.4. Developers who don’t care about code quality
Also, there’s no need to do overtime if the company is not paying you to do it.
4. Developers not caring about the code quality
We are developers and we love to code, we are passionate about it and want to make software that the world can use.
Writing code is a craft and this craft needs to be practiced and perfected as years of experience grows, but unfortunately, not many devs have this mindset and majority will not even care about how they write the code as long as it’s doing what it’s supposed to
The best argument that these creative developers will give is
“Dude I know I have written 400 lines of code and have tight coupling across the project but it works”
There’s something called technical debt (programming version of karma) and this will slowly bite the team, soon to make small changes you will take a lot of time because if you make small change or introduce a new feature then something else breaks.
When this happens, the managers, BA, client, the director of the company everyone is frustrated that why a small change is taking so much time.
Such codebases are extremely fragile and the worst thing could be the developer who worked on this codebase is no longer with the company anymore and there’s no documentation about it.
Solution: When you get a new module don’t just run towards the keyboard, take your time think about how you will code, take a pen and paper and design the flow using a sequence diagram and try to implement concepts like single responsibility.
Conclusion
In the end, I would like to say that when a project is successful we all are happy but if it fails we all are sad because its not one person who has failed it’s the entire team.
The seniors/leads need to sit with the management and be reasonable and clear with the count of stories they will deliver and communicate way ahead of time in case of any impediments.
The senior/lead should also know when to say NO to the management, this is a skill that senior developers must learn.
The management on the other hand needs to make sure that they are working with the development team and not against them and not adding any other user stories or change requests in the current sprint.
If we all follow discipline and communicate and developers implement clean code practices with test cases then I think that could avoid project failures.
Let me know what you think about the article or share any tips that you have used to avoid project failures so far
