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 – and we need to avoid gold-plating throughout our Agile delivery process.
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 the 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.
Kiron D. Bondale, PMP, PMI-RMP has managed multiple mid-to-large-sized technology and change management projects, and has worked in both internal and professional services project management capacities. He has setup and managed Project Management Offices (PMO) and has provided project portfolio management and project management consulting services to clients across multiple industries.
Kiron is an active member of the Project Management Institute (PMI) and served as a volunteer director on the Board of the PMI Lakeshore Chapter for six years.
Kiron has published articles on Project and Project Portfolio Management in both project management-specific journals (PM Network, PMI-ISSIG journal, Projects & Profits) as well as industry-specific journals (ILTA Peer-to-peer). He has delivered almost a hundred webinar presentations on a variety of PPM and PM topics and has presented at multiple industry conferences including HIMSS, MISA and ProjectWorld. In addition to this blog, Kiron contributes articles on a monthly basis to ProjectTimes.com.
- Why You Should Become an Atlassian Certified Administrator - February 20, 2017
- The Shape of Modern IT Teams Practicing ITSM - February 17, 2017
- New Features in Portfolio for Jira to Improve Your Roadmap - February 13, 2017
- 4 simple collaboration strategies for distributed teams - February 2, 2017
- Documentation Establishes a Single Source of Truth - January 24, 2017