I appreciate one of the AGILE Principles stating:
“Simplicity–the art of maximizing the amount of work not done–is essential.” Not that I want to limit the work done, rather wish to identify the fine line between “work-that-can-be-done” and “quality-work-that-can-be-done”.
Most of the times, it’s rather too late before we realize the amount of work/tasks committed to are practically next-to-impossible (not atleast unless you have those zombie developers and testers on the project who can work like 12-16 hours a day!) . On Project’s front, it might result in compromise in product quality, delay in delivery, project going over the budget. On the People’s front it might require overtime by employees and stress them. None of these sound very good for an organisation or any Project
Following are a few things where we can/should learn to say NO in the IT world occasionally as and when required:
* Account Managers should say NO to customers if the quantum of work cannot be handled by the people sitting at desks in office. It always feels great to show your customer that you can provide XYZ and probably ABC as well but it shouldn’t be done at the cost of draining out the team.
* Project Managers should not commit to Project delivery unless the deadlines are in agreement with the team capabilities, strengths and weaknesses. Admitting that something cannot be done within the given timeframe is not wrong, it’s just being proactive to avoid a lot of probable upcoming Project and Product risks.
* Developers might need to say NO if they think they can’t deliver a quality product to QA because of time constraints. Yes, QA is supposed to find bugs but everyone is responsible for quality in one way or other.
* QA is never expected to YES for something which might work unless you have SEEN it working , literally. As part of QA team, you are the ones who are looked at for that stamp of quality.
NO can prove to be a magical word is used wisely at correct time!!