Everyone loves a good metric. As product managers, we probably proudly proclaim that we are getting better at making decisions based on data rather than gut instinct. How everyone gathers, visualizes, and uses information — in product management and beyond — has certainly changed for the better over the years. In the past, we were overloaded with data and graphs to the point where we couldn’t see the forest through the trees anymore. But now, we have learned to become more selective. Now the few, hand-picked metrics we use should all be driving decisions and be highly actionable, right?
Have you ever wondered how import leaders (Product Owners, Scrum Masters, Tech Leads, and stakeholders) are when it comes to the health and productivity of Agile teams? Well, I looked at the data and here is what it says:
Distributed Agile teams may not be the norm, but they’re here to stay and their numbers are steadily growing. In my own experience, they can work pretty well and become quite productive (see my prior post), although there always seems to be a “remote penalty” compared to fully co-located teams, basically the inevitable cost and friction introduced by not being in the same place.
Is it possible to boost such a team’s performance further and reap benefits similar to co-located teams? Can you “virtually co-locate”?
A recent experiment has convinced me that the answer to these questions is “Yes”!
The Starting Point
I was working with a “regular”-sized Kanban team that had already worked together for a while and found its stride. Members were located from the US West Coast, the Mid West and Florida to South America with a maximum time difference of 4 hours. Things were going pretty well: We were conducting the typical Agile ceremonies via Zoom sessions, used Azure DevOps to manage work, collaborated via Slack, and had working sessions and meetings as needed.
The team had been working on a new module of a SaaS application and we were faced with the challenge of delivering the MVP within about 5 weeks, which was doable, but not easy. We discussed how to work together differently to intensify our efforts and increase our chances of delivering on time.
We had the option of traveling to a central location and work together in the same office for a few weeks, which obviously carried not insignificant costs such as travel time and expenses, logistical challenges including visas, and being away from our families. While we left that option on the table for later, the team decided to try out a different set of working agreements first.
Prioritization of work is hard: it’s often more an art than a science. Unless you work in an organization that has mastered the delicate balance of work from a prioritized roadmap as well as customer requests, you too may often be faced with squeaky-wheel prioritization: The customer yelling the loudest (or the one who last spoke with sales or the CEO) gets what they want.
We product management professionals thought there must be a better way to figure out prioritization, one that’s more “scientific” and less subjective. So various schemes for prioritization emerged from the industry, looking at the benefits of features such as new revenue, customer retention, cost savings, … you name it. Either one or multiple of these factors were being considered and summarized into terms such as “business value”. Agilists quickly pointed out that absolute values (e.g. dollars) make things hard to compare and that measurements are often imprecise, so we started thinking in relative business value points.
Great, so now we have a way of systematically prioritizing our features, right? As long as we work our way down our feature backlog in descending order of business value, we’re making sure we deliver the most value to the business and we solved the problem of old-school prioritization, right?
Well, not so fast, cowboy… (Continue reading this post on MindTheProduct where it has been published in its entirety)