The understanding of a project changes through time as its development continues. Following an obsolete specification, creating only a superficial domain model or coming up with shady half-measures – to avoid any profound effort – won’t stop you from delivering an app, but most definitely it won’t be the app that was needed.
There is always a moment when you have to decide whether to adjust to the freshly revealed facts or to stick to the agreed consensus.
To put this issue into context, ask yourself if you really value the agreed specification more than the interest of people affected by your work. If you care about the people, you should follow blueprints only as long as they are relevant. With feedback from end users and the product owner given frequently, they become obsolete quickly. You should take care to update specs to reflect recent feedback. That way you can be sure that you utilize your team’s effort towards something that solves the problems that were meant to be solved.
Agility was introduced to software development to cope with the fact that it is impossible to define a complete product at the start of the project. The project’s scope and its objectives are fluent from the very beginning – they will change every time the stakeholders or end users are presented with the latest version of the application. Not keeping these groups in the loop on a daily basis spells disaster. Furthermore, blocking developers from communicating with them will only result in huge divergence between what was achieved and what was expected. The inevitable pressure put onto developers to quickly bridge the gap before a looming deadline is bound to result in disappointment, especially if good practices are skipped in favor of a rush to production.
In the end you will end up with an overpriced, delayed project that not only will not satisfy the needs of the end users but will also be extremely costly to maintain – all of this in the name of illusion of control and fast progress.
Once the project ships it will be hard to identify the issues that lead to its lack of quality. From unengaged stakeholders, through unassertive developers to managers who are unwilling to learn more effective approaches, we end up with dissatisfied and disappointed users and employees suffering from burn out. The most devastating result, though, is an application that no one enjoys using and nobody wants to maintain.
When you see developers only as code monkeys you will get only what code monkeys can deliver. If you include them in gathering requirements and let them communicate with end users, the result will not only satisfy all interest groups but will also be more likely to exceed their expectations.
Photo by Anthony Tran on StockSnap