Having to make product and technological decisions constantly can become problematic or even overwhelming over time. You may find yourself having to deal with tense situations where your product or the tech aspects don’t yet meet target expectations. For example:
The development team(s) won’t be able to make delivery on time due to infrastructure dependency that must be taken care of before proceeding with the business logic implementation. e.g: “We need to understand where we can store X to achieve the data fast enough”.
Your team came up with an unstable issue that could potentially kill consistency. e.g “If we don’t apply a retry on that rest API call we might lose data”.
Scaling questions and anxiety. E.g. “If we don’t optimize our threading configuration from X to Y sooner or later we won’t be able to scale”.
I’m sure many of us are all too familiar with similar use cases. The point I’m making here is that not all use cases need to be taken care of in the same release, as some of them can be added into a “pending queue” until the time comes. How can we tell which ones to Stop, Postpone, or even Discard?
Let’s start this discussion from the bottom moving up by solutions:
Cutting using Product
Product has a tendency to reach for the “moon & stars” but we as the delivery team need to keep things down to earth, focusing on the most necessary requirements from day one. Scoping and expectation settlement will help to achieve optimal results on time.
When you reach a point where you need to face an unexpected and tough “blocker” from dev teams you probably will have three choices:
- Try to draw a new solution
- Add complicated workarounds
- Bring on product decision-makers to overcome this
From personal experience, option number 3 is always the fastest and most efficient way to resolve the issue. Product in their nature is always willing to compromise for the big picture. You have a better chance as a delivery team to settle with your product by cutting some pieces from the cake than adding too many efforts to face your current blocker (of course this is not always true in some cases but for the majority, it works).
How do we approach our product with such a use case? Come prepared. A good understanding of the requirements and spec motivation will be an enabler for a good proposition to cut off-spec requirements for the sake of delivery. Use case example:
“Your SDK team comes with a new component that they struggle to implement due to a library versioning conflict. It will draw back the timeline (upgrades, testings, etc..).What do you do?
First, understand if the component can be implemented in non-backward-compatibility way or perhaps shrink its requirement to a non-conflict version delivery. If that goes well propose to your product a solution and see how it goes.
NB! Add to your backlog an “upgrade framework” task on an additional timeline for critical issues. : We had to implement a new email system that aggregates players who have won games while notifying the customer as well. We knew that in cases where we failed to aggregate the players (any internal error) we would have to send the customers two emails. One for success and another for failures. The team didn’t like that we sent two emails one after another. To fix that we had to merge two logic services as those emails were being sent from different sources. We proposed to the product additional solution: Add to the first email a new line: “In case of failures a separate email will be sent”.
It took 2 minutes to overcome this “blocker” compared to an infrastructure sync of those two services. (We still added this to the backlog to make it right but we held the blocker aside for the sake of going live)
Cutting using business compromises
How many times have you found your development teams(s) struggle for days on end to bridge an edgy use case which eventually delays delivery times? For example:
The team(s) highly suggest that you should 100% secure any failed use-cases that require an infra upgrade.
“The infra team claim, “To achieve a fully retry mechanism you must persist additional requests to other data structures to avoid data loss”.
What do you do? Every development manager or stakeholder when they hear the “losing data” threat they find themselves helpless as they are forced to agree.
But hey… what if we ask first: Is it really necessary at this time to solve this open-issue which might happen about 0.03% of all time?
I mean don’t get me wrong, we do need to take into consideration the worst-case scenarios, but it’s not an all black-or-white question. We do have an in-between and for the most part, can consider taking business compromises on a “negative” scenario flows at the first scope. Another way to solve this would be to make an assumption:
Let’s assume we hit statistically 0.03% of use cases and we lost an event while our machines were down and didn’t manage to recover. What if we could draw a “manual” solution for the sake of this delivery? What if we could solve this in another creative way and postpone the ultimate solution until we first deliver? Software is something that evolves and grows. Give it a chance to get there and your solution could be much more effective than preparing everything in advance.
Another example: We were building a social network where players can login and chat with each other on a public channel. Chats are temporary and should be closed once all participating players log out. For us it was a tremendous challenge to know when all players are logged out to discard the channel and to remove its resources. The best way to bridge this was to make a business decision: We decided that if there are no new messages in the channel for X hours (assume 24H which is by far more than the average player session time) we will discard the channel and revoke its resources.
Making out of the box solutions using business decisions can cut through delivery time drastically.
Cutting using Customers-involvement
In my opinion “recruiting” your customers to the mission is the most valuable option. Being transparent and engaging with your customers on the delivery status will minimize future surprises and will align expectations.
Use case example: The team has committed to a certain product scope based on an estimated timeline. Unfortunately, the PM got bad news and it looks like feature Z, which was agreed upon, won’t make the deadline and the customer won’t be able to accept the delivery as expected. What’s next ?
- Push your dev team to death to make it (it most likely won’t work)
- Cut feature Z into pieces and try to deliver something
- Let your customer know that you are struggling to release Z (as a whole)
I suggest based on my experience the solution for this scenario is a mix between point number 2 & 3. Showing some results is better than showing nothing at all. I would try to take feature Z and cut it into (even more) smaller pieces and deliver partial functionality. Next step,l create a status meeting with your customer (asap) to renew the expectations. Most of the time once you are aligned with your customer there is a happy ending on both sides. So being transparent in this situation and delivering partial results will most likely get you out of a bad situation.
There are endless creative ways to bridge development blockers and as much as I admire technology it’s not always the efficient direction to take on certain situations. Keep in mind, there is a time and place for everything.
Idan.
| Published on Java Code Geeks with permission by Idan Fridman, partner at our JCG program. See the original article here: The Art of Cut Opinions expressed by Java Code Geeks contributors are their own. |
