A lot of organisations who expect their development teams to apply agile methods and practices forget to include the rest of the organisation in said practices. This causes all sorts of misconceptions.

Stakeholders and product owners often treat agile development as a means to “solving things as we go along”. As if agile development somehow exempts them from the need of doing proper ground work before building.

While the “solving things as we go along”-notion is not completely untrue, it’s a distortion of the intended concept. A flawed phrasing, if you will. Agile development is about building software with the acceptance and expectation of changing specs – not with the absence of specs.

The Agile Manifesto phrases it as

Welcome changing requirements, even late in development.

Some seem to interpret this as “requirements can be defined when developers ask for them”, which is a completely untrue statement. All requirements need to be written in time before the developers need them. Preferably they should be written, reviewed, re-written and reviewed again before the developers need them.

Requirements can be changed, added, or scrapped, even when in mid development. But when a developer is handed the task, there should be no ambiguity as to what the goal and effect of the code should be.

The more requirements and specs that are written before development starts the better. This helps the developers to see the whole picture of what they’re trying to achieve. It also helps with prioritising, and potentially cutting or adding to the scope.

So instead of heading into development thinking “we’ll solve things as we go along”, the attitude should be:

To the best our knowledge, do we have all the information
to see this feature through from start to finish?

The Scrum concept of a mutually agreed Definition of Ready is very helpful for this. What needs to be in place for development to begin? Are we lacking data? Are we lacking user stories?

Only when Definition of Ready is met can the team commit to development.