The market demands in Fintech rise quickly, forcing companies to make creative moves and augment their development forces. You might have already observed the talent shortage trend on the local market and plan to use an alternative workforce, or you may just consider scaling in-house. That’s not the point. The point is any changes in the structure of a team are aligned with stress and risks. At first glance, it may seem riskier to hire people somewhere far away and treat them like regular team members. They may lack experience in your area, use other practices, or do something else that could cause strain. The only reason this can become a problem is that your current team has some internal problems, and scaling can catalyze their negative influence.

In this piece, we describe work situations that may seem usual for some, but beware—they indicate your team is in danger of scalability problems.

What is this?

The startup-like atmosphere is an impartial element of young Fintech companies. Split roles, fast changes, and limited resources all come along. Usually, the founders and cofounders at such ambitious companies combine several roles at a time, eliminating each other’s weaknesses and trying each to make a bigger impact. Unfortunately, they lack time to cope with everything they want to do.

A hypothetical company, Pineapple Wealth, is of just that type. Once, before a sprint starts, the product owner (let’s call him Bobby), who is also a cofounder and jack-of-all-trades, describes how a new feature should work. As it happens, the logic of the feature isn’t as obvious for engineers as he thinks, and developers don’t understand it clearly enough to start implementing. While other colleagues try to figure out what to do by themselves, one of the developers, John, decides to message Bobby and ask him for help. He says there are too many points that can be mistreated and asks Bobby to create a user story where all ambiguities are ironed out. Unfortunately, Bobby doesn’t have time for that. He asks John to create a user story and send it to him for review so that they can ensure they are on the same page. John, of course, doesn’t have enough perspective to create a story well, but because he has nothing to do, he prepares some short story to facilitate the process and shares it with others in a team chat.

Meanwhile, Bobby finally finds time to create his version of the user story and also shares it with developers. John finds this version unhelpful and decides to start working on the story he wrote by himself. His reasoning is this: (a) Bobby didn’t make corrections to his story as they negotiated, so John considered it agreeable; and (b) Bobby hasn’t assigned his user story to John.

After days of hard work and debugging, the demo day finally comes. John presents his solution to Bobby and other Pineapple Wealth cofounders. The following is the question he has to address after his presentation:

–       “John, what is this?”

Feeling confident and proud of the solution he has provided, John shows the user story he personally created to the board.

–       “What is this?”

Needless to say, the user story and the work done turn out to be far beyond what is necessary. Pineapple Wealth fails this sprint, which freezes other departments and developers for several weeks.

Lessons Learned

The process of creating, explaining, and assigning user stories should not be sacrificed for the sake of other important tasks. If you don’t pay enough attention to your user stories and their quality, you will definitely have problems.