This is the second of two parts on gold-plating. You can find part one here.
The manifesto for agile software development defines simplicity as ‘the art of maximising the amount of work not done’. For first timers, this may sound counter-intuitive but working smart, not hard is one of the key principles of agile scrum.
Getting to simplicity, however, is not always easy. To achieve this, start by having an open discussion on which elements of your workflow can be improved and simplified. Once you’ve come to a consensus on this, seek simplicity in the work items. Think about how to deliver the same value without spending as much time and energy. This might mean thinking about different solutions a little bit longer in order to save hands-on product development time and effort. This is true value delivery.
Be sure to honour this agile principle and return to it whenever you feel things are getting unnecessarily complicated.
“Simplicity–the art of maximising the amount of work not done–is essential. Work smarter and not harder.”
Another way to defend against a habit of over-engineering is by using ‘built-in control mechanisms’. These are simply tools for team collaboration, which include pair programming and peer review.
With pair programming, you might pair one team member who’s prone to over-engineering with someone who isn’t. The result is that they help each other to find a sweet spot for fidelity and quality of the work, in alignment with the team’s definition of done (see part 1). This also has a positive effect on team development.
Peer review, like pair programming, helps team members check their peers’ work for signs of over-engineering. Peer review is almost routine in development teams but can be rolled out across different disciplines. It’s especially useful when pair programming isn’t an option.
OK, maybe not grill them, but definitely have an upfront conversation about their expectations when it comes to the fidelity of the work. This chat should be had as early as possible and it’s important to make sure the agreed level of fidelity aligns with your current position in the product lifecycle. Ask them e.g.:
It is also worth regularly checking the competing offering in the marketplace for their level of fidelity to ensure your product stands out just enough in a great way.
Lastly, do what you can to create a culture that embraces low fidelity work, as these are the teams that work faster, iterate quicker and deliver and ship more often than any other. You can always adjust up. Starting from the lowest fidelity appropriate is an easier starting position overall.
I hope the video and tips above help you to combat the all-too-familiar desire to gold plate, both in refinement and during the sprint iteration. From here, I’d advise you to watch part one of my tips for avoiding over-engineering in agile scrum.
If you have any questions or topics you’d like me to cover, leave a comment below or send me a message through my website. Thanks for reading. See you next time!
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.