Avoid gold-plating through agile delivery

As it is with jewelry, on projects gold-plating is all form with no substance. The increase in costs is rarely justified by the value provided by superficial “bling”.

It could be an analyst adding in requirements which they came up with on their own without ensuring that those are actually required, a developer who introduces a code change or feature they believe is useful without checking with others or a quality control specialist who decides to test above and beyond approved test plans.

Don’t get me wrong – the intentions are usually good and I’ve yet to encounter an instance of gold-plating which was done maliciously. But it doesn’t matter – gold-plating is work creep.

What’s the worst that could happen you ask?

On a project which follows a traditional or waterfall delivery approach, that innocent feature which the developer added might cause regression to approved functionality but at the very least when it finally gets identified will generate unplanned work for other team members. Scope definitions, requirements documentation and other work products which had been produced, reviewed and formally approved will have to be revisited. And the magnitude of the rework and incremental effort increases the further the project gets into the delivery lifecycle.

But on an agile project, if a work item is elaborated beyond the Definition of Ready or the Definition of Done, this will become apparent a lot sooner. Increased transparency into all development activities reduces the likelihood that such changes will propagate beyond the iteration in which they were introduced. Non-solo development practices such as pairs programming can weed out gold-plating at point of application.

A good agile project team exhibits self-discipline and self-organization. Behaviors which impact the team’s ability to meet its iteration commitments will be addressed swiftly else velocity will decline.

And let’s say the team member who is tempted to gold plate feels very strongly about the specific change they’d like to make. Unlike on a traditional project, there are ample opportunities to review it with the product owner, analyst and other team members to assess whether it merits being added to the work backlog.

Using agile approaches to deliver a project provides no guarantee that gold-plating won’t occur. After all, it is a function of human behavior, not approach or methodology. But agile lifecycles can make it easier to detect and prevent future recurrence.