Photo by Michael Weidner on Unsplash

This article is about delivering value. We all want to deliver value. Regardless of the method that you adopt for your projects, you always want to deliver value to your organization. Now that we are on the same page about this, let’s talk a little bit about quick wins.

Quick wins or low-hanging fruits are those small successes that we generate when we start working on anything new. Here some examples:

You get hired. After a complicated and energy-demanding selection process, you are now part of a new team. You do want to show the organization some quick wins so the organization that hired you can confirm that they made a good choice in selecting you for the position (and you can pass the probation period!).

You have a promotion. So now you are surrounded by the same colleagues, your badge shows the same company logo, but you have a new title. More responsibilities, other challenges. Guess what? You also work on your quick wins. They may be part of your 90-day plan to succeed in your new role. You are again looking for approval, looking for quick success so you can demonstrate that you are up to the new challenges. That also helps you cope with your impostor syndrome, by the way.

Now let’s change gears: you are not freshly hired and you haven’t been promoted lately. But you were given a new project: the implementation of the Purchase-to-Pay module of the ERP that the organization chose to adopt a couple of years ago. This is something new. And big. Hundreds (if not thousands) of employees will be affected and will need to change the way they acquire goods and services. Sooner than you think, you are already thinking about how you are going to organize the work:

“I think I need a project charter. And a WBS. I may also need a Gantt chart. Or I may propose to manage the work using an Agile methodology… Above all, I need to deliver something quickly”.

These are some of your thoughts. But you will also soon think about which quick wins you want to deliver. Not only because you want to make it clear that you are the right person to manage this project, but also because the organization needs to get some momentum, the project needs some initial traction (after all, the timeline that was given to you is obviously tight).

Having managed a P2P implementation project myself, I know how important quick wins are in such a context. Especially if there is some resistance to the project in the air.

What do all these examples have in common? Quick wins. But why do we want quick wins in all these cases? Because we want to show quick successes. Small successes, bits of victories that will put a smile on some anxious faces in your organization — or on your own.

When you work on quick wins, you are looking for delivering something successful, not necessarily valuable.

Now, let’s look at the other side of the medal: what quick wins are NOT about. Quick wins are not always about delivering value. And this is when the Agile mindset comes into play.

Agile methodologies strive to deliver the most valuable items of a product first. It is important to maximize the ROI of the project by front-loading the deliverables with high-value user stories, requirements and features. This is the main factor we use in the product backlog grooming exercise: business value. We prioritize items based on the value they bring to the organization. There is little or no consideration of the effort that it takes to deliver what needs to be delivered. The goal is to use the value of the various items as the main driver to determine which items will be developed first.

We can also factor in the risk of some features to help us prioritize items in our backlog. So when we apply the value and the risk of each item as the criteria to determine the priority of the items in our backlog, we build what we call a risk-adjusted backlog. Note that the effort or the time it takes to deliver the items are not part of the criteria.

So in Agile projects, we don’t necessarily want to have quick wins. We want to deliver the most valuable items first.

But there is a caveat: what if a product owner determines that putting a smile on people’s faces within the first month of the project is something very valuable for the organization therefore a quick win will be a good way to accomplish that? Well… Now quick wins may move to the top tiers of your backlog. Note, though, that there is a reason for that.

Agile projects don’t harmonize with the impostor syndrome or the need to prove competence because being agile and working in an Agile environment means that there are trust and transparency.

For this reason, if the Product Owner doesn’t see real value in quick wins, don’t go that route. Focus on the value of what you need to do. Prioritize wisely and your organization will be thankful.