Planning is key to Agile development

When I saw this meme, I just had to laugh. Then it got me thinking about how wrong this picture really is…

It is a total fallacy to suggest that there isn’t any planning (or plan) with Agile development or that Agile results in poor quality.

If anything, there is more planning with Agile development than with traditional “plan driven” projects. It may not seem like it, because planning is a continuous activity happening as the work progresses. The “plan” itself is expressed in a very different form i.e. as an ordered list of work items that can be continuously re-prioritised by the business, to deliver the higher value items sooner. This kind of plan supports better commercial decisions. It is clearer to everyone where we are now and better at forecasting how long it will take/cost for further items to be delivered.

Unlike traditional “plan driven” projects, Agile development is all about quality. Quality becomes the responsibility of the whole team, who work to a robust Definition of Done. This ensures that each item of work isn’t considered complete until it is of serviceable quality. The steady release of functionality to the customer not only delivers value to them sooner, it provides fast feedback making it easier to manage risk, especially those around getting the product increments into live.

Agile avoids the situation alluded to in the picture through highly discipled engineering practices such as Refactoring, where the internal structure of the system is continuously improved with the support of automated testing.

Agile does a better job at managing risk and stakeholder expectations, leading to better outcomes.

If absolutely necessary, Agile practitioners will compromise on scope, but never quality. With traditional “plan driven” projects the quality is compromised because the quality assurance happens at the end, where it gets squeezed by the inevitable and unforeseeable problems that will emerge.

In my experience, projects that begin with a long up-front planning/design phase still ended up with software that looked like the wires in that picture. This happened because when the plan/requirements/design/architecture were established up-front, it was impossible to know what was really needed and what the best technical solution would be. By the time anything got delivered, it was late, of poor quality and didn’t do what the customer had now discovered they really wanted.

The Agile approach enables planning that is far better at dealing with the emergent nature of software product development. Planning is continuous and quality is key. It is highly disciplined and difficult. It isn’t often you see it being done well, so maybe people can be forgiven for misunderstanding what Agile is really all about.