This is the second of two parts on gold-plating. You can find part one here.
Tip 1: Seek simplicity
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.”
Tip 2: Put your peers in pairs
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.
Tip 3: Grill your stakeholders
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.:
- is the user’s current need met? If so, how? It could be that the user need is well understood, but the current solution is highly suboptimal. If so, fidelity should be kept lower. Anything is better than nothing when there are intentions to make improvements later. Also you’ll need to learn and get feedback quickly, so that the new solution really works better than the current solution..
- Is it an established product with a growing user-base? If so, what is the current delivery rate? Was there a big push to release more and more features, so that now it takes too long for new features to be added? This points to ‘technical debt’ that is accruing the bad kind of interest. Keeping the fidelity level the same, and more short-term focus on code quality is needed, than features, to reduce the cost of delay, and cost of carrying suboptimal code.
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!
Here’s the full transcript:
-Hello, Georg Fasching here helping you unlock your team’s genius.
In this video I’m focusing on gold plating or over engineering of your product features, and this is actually part two in a two part to share with you a total of six different things that you can do to get a handle on this aspect.
And as usual, in videos in the Power of Three series, I am spending three minutes to share my top three tips and encouragements on a particular subject, and with this one you’ll get a total of six things that you can do to get a
handle on over engineering and gold plating, so with that let us put three minutes on the clock starting now.
So, the first thing, or the fourth thing is to remember one of the agile principles to work smarter not harder, the agile principle says simplicity, the art of maximizing the amount of work not done is essential and by that we mean to be really, really clear on all the things that we can cut out in order to still deliver the same value, and working smarter, not harder.
Use a little bit more time to think of how a feature could be created in order to deliver the same value rather than going with the first solution that seems to be the most obvious or apparent just to spend more time thinking of a more creative and simpler solution to address the same problem for the users.
So simplicity is key, and remembering to honor that agile principle is definitely something that should be done on an ongoing basis.
The second thing I would like to share with you is to actually use built in control mechanisms in the way that you work in the team, and two good things are peer programming and peer review, so if some team members declare themselves as perhaps being prone to over engineering things, then they compare themselves with somebody who is quite happy not to do that and they can help each other on that front, so peer programming works well for the developers to also keep that in mind as they’re working through that together.
And peer reviews can be done in other disciplines in other types of roles as well, and is also a good option, peer review will also help you if you don’t want to take up peer programming as an engineering practice but
of course you would want to do peer review of your code
and part of the peer review check could be to see whether
there is some over engineering going on on the development of those features.
So that was the second thing.
And the third thing I would like to share with you is to actually, from the very beginning, with your stakeholders, ensure that you have a frank conversation about what their expected level of fidelity and the expected level of quality is.
And with that it is worth bearing in mind to appreciate where the users are currently going in order to solve the user need, to solve the problem.
If it is a completely unmentored need at the moment, which is unlikely, then anything that you do will be better than what they currently have.
If it is a complete leap frogging, and say currently they’re using a paper based process, and you’re doing service design and figure out that actually there is a much better solution than paper, that will already be a leap frog, and actually as a team and with the stakeholders bearing in mind what the totality of the
improvement is, will already be an encouragement to then
say well, given that we’re already going so far, but
what is now the simplest way of doing this leap
frog and this step change and have an honest and
frank conversation with stakeholders from the
beginning to make it okay to develop to a certain level.
And with that, the three minutes are up.
Thank you very much for your time and energy as usual.
If you have any thoughts, queries or comments
on this particular video, or any ideas for future ones, please leave them down below in the comments.
If you found something useful in this video, please ensure that you like, share, and subscribe in order to help spread the word.
It would be much appreciated.
So with that thank you very much and all the best for the practice with your team, and goodbye.