Gold Plated Software
The first time I saw gold plating used as a description for software was in a paper by Barry Boehm where he gave the following root cause:
Gold plating. Fixed requirements specifications in advance of design
tended to encourage software gold-plating. Users asked about their
requirements would frequently reason, “ I don’t know if I’ll need
this feature or not, but I might as well specify it just in case.”
In his description, he recommends using methods described in his research including the spiral software life-cycle model in which projects were scoped to produce a series of prototypes one per cycle, and as the spirals got bigger, a full featured product. Spiral had wide spread influence among software researchers, and was an important bridge between waterfall and Agile. A critical limitation of spiral is that each time around the spiral, cycles got longer and more expensive.
As with Agile, spiral tries to avoid gold plating by scoping more narrowly and scheduling the project deliverable long enough that teams can finish the requirements, while at the same time being short enough to permit focus on the goal from day one until delivery day. One way that Agile methods like Scrum are superior is that Scrum sprints for a time frame that does not get longer with iterations. From the paper, project management seems to have more influence on gold plating than than individual developers.
Talent for Time Boxing
Being able to time box is very important, but it is not a binary skill. You don't have it or lack it. You are better or less good with it. Whether it comes from your boss or from you, I would prefer if no one said that you can't stop gold plating. That sounds to personal, pervasive, and permanent.
A root cause analysis might help identify several issues. I am quite certain they will not all be pointing at you, and that unless you work with psychopaths, others in your team will see similar needs to improve their Agile skill set. If you know someone without problems, you don't know them very well. If you know someone who thinks they don't need to improve, they don't know themselves very well.
I hope improvements you identify will be things you can solve with your own awareness and help from the team. However, I think that is not where this ends. My expectation from the supervisor or manager who writes your reviews would be that they can also coach their subordinates to be successful. This is particularly critical when the organization is undergoing a revolutionary change like switching from planned to Agile (or ad-hoc to Agile).
Quick and Dirty or Risk Managed Prototype?
I had a manager who used to request that tasks be performed in certain way.
Quick and dirty, but a thing of beauty.
He knew the silliness of this, and it was part of his wry sense of humor. Many people say things like this and they are dead serious. Somewhere, there is a compromise or an opportunity to ease the problem with an improved technology or approach.
What can we sacrifice to fit our time box?
In chapter one of Extreme Programming Explained, second edition, Kent Beck talks about what it takes to move fast. His answer is that "you do only what you need to do to create value for the customer."
Risk
In the first edition of the same book, Beck identifies a little more closely with Boehm's views about controlling risk as being critical to his methodology by saying:
"Risk is the basic problem of software development"
In both editions, Beck lists and describes eight common risks, followed by an assertion that XP (or perhaps by extension, Agile) addresses each in a particular way. For me, most of his explanation boils down to use of smaller increments and faster iterations allows us to steer things back on course before the risks grow too big to handle.
Mentality of Sufficiency
Beck discusses resources in context of a story about the Mountain People and the Forest People and introduces a concept called the "Mentality of Sufficiency". In the context of your situation he asks "How would you do it if you had enough time?" Just this one first chapter, available as a book preview, may provide a lot of food for thought about how XP (and other Agile methods) think about constraints like time.
Compulsion Might be the Symptom, Not the Disease
Years ago I looked at a book about procrastination that stated that a lot of procrastination originates in fear. If you don't start, you don't make a mistake, and maybe you won't be criticized. Compulsion and perfectionism gives something that our moral sense tells us is better than procrastination, but probably has the same result. Consider that perhaps you are having a problem with procrastination in another form?
Criticism and Competition
In Agile methodologies like Scrum, opportunities for being criticized or punished for procrastination have never been higher. That is a vicious cycle. I procrastinate because I am criticized, I am criticized because I procrastinate. With daily scrum meetings, we are always on alert because we are always a day or less from reporting to the team what we accomplished.
In an ideal team, Scrum gives a daily opportunity to correct procrastination. Mistakes should not have time to get big before help arrives. Teams are not always where they should be trust-wise, so leaders within the team may need to proactively address either criticism or the fear of criticism to permit things to move forward.
In our world of work, each person on a team must also compete with others. It is a little bit schizophrenic to believe in having a team that shares the work and the glory for accomplishments, but then use an annual performance management process that rewards 20% of its members, punishes or expels 10% or more of the members, and pretends that the 70% majority contributes its best without incentives. I think this is a big elephant in the room WRT promoting teamwork, and to reference Kent Beck's story, it shows deep cultural ties to being Mountain People.
The Way Forward
As a member of an Agile team, it would be good to study and dialog with others about what works. If your team is using TDD to automate their unit tests with a tool, get the person who does it best to coach you. If your supervisor or manager has a problem with your documentation approach, find out what he likes or who is doing it the way he likes, and follow their approach. If it boils down to raw coding speed, investigate what it takes to code faster.
Leaders can take steps in the right direction by role modeling desired behaviors like candid talk about their own problems (not someone else's), offering and following through with help, having a dialog about how the team can move to Agile Marine style (i.e. no man left behind). Not everyone on the team has the same abilities. It may be appropriate to explore pairing team members or assigning tasks and roles that can emphasizes complementary strengths of the people involved. Planning for the growth or remediation of skills should be a rewarding part of the job both for the supervisor and the subordinate, but must happen early and often to be effective.
