Three more ways to deliver real value pt.2 - Unlock Your Team's Genius

Three more ways to deliver real value pt.2

By Georg Fasching | agile practice

Oct 25

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!

Follow

About the Author

An agilist since 2010 and in product management since the 90s, Georg Fasching helps digital creative agencies delight their clients, fulfil their people, and improve their prosperity.

>