Pragmatic Coders

What evidence can you share that demonstrates the impact of the engagement?

The product is still in the beta stage, so we don’t have any concrete metrics to discuss. We’re currently about five weeks away from launch.

This may be due to our lack of knowledge, but we’ve certainly been surprised by the extent of their delivery. They’ve made great progress in a short amount of time.

How did Pragmatic Coders perform from a project management standpoint?

Their project management has been excellent. After the discovery phase, Pragmatic moved fairly quickly into running everything using agile methodologies. The team tracks the project backlog in Trello and uses Jira to manage development tasks. They’ve been meticulous with their documentation and planning.

The only less than great experience that we’ve had so far came when we split the teams. There wasn’t always the best communication between the teams in Warsaw and Krakow. Also, the handover from the Krakow team to the Warsaw team wasn’t as good as it could have been. These things tend to happen when you have two separate groups trying to work together. Aside from this, the core team has been really phenomenal.

What did you find most impressive about them?

It’s very notable that they were able to kind of challenge our views on how we should build trading software. We’ve been surprised by this, because, although they had some experience with trading systems, they didn’t have experience in the specific field that we’re operating in.

Also, the relationship that exists between their product owner and their development team is extremely good. Pragmatic seems to have solid communication within their development team and their team as a whole. One of the biggest risk factors we’ve faced is a team that isn’t cohesive, because that will slow down a project considerably. Their work environment and communication are second to none.

Are there any areas they could improve?

My suggestion, which I’ve already made to Pragmatic, is to review their relationship with the third-party vendor that we used. They weren’t the strongest firm, at least based on the work that they provided to us.

Pragmatic also has a relatively narrow focus in terms of the types of solutions that it offers. For example, they didn’t do mobile development and didn’t have an internal UX/UI team.

We’re going to be transitioning away from Pragmatic in the coming months, because, unlike many other software shops, they don’t offer any kind of mechanism for transitioning into a permanent team. We’re hoping to find another partner on Clutch.

Pragmatic has a business model that I respect, but we’ve been forced to reset our project because of it. My strong suggestion to them is to think about being more flexible and to consider implementing a build-own-transfer model.

Could you share any evidence that would demonstrate the productivity, quality of work, or the impact of the engagement?

They were just a part of the team. It might be difficult to share stats on the part they were working on.

How did Pragmatic Coders perform from a project management standpoint?

They work directly with our team. We’re happy with their work. The communication is good. Deliverables were OK. It wasn’t always 100% on time. They weren’t all to blame for that though.

What did you find most impressive about Pragmatic Coders?

They improved our tool for internal messaging. Because of that, we could reduce the number of servers by 20% because it improved a lot. I wasn’t involved in the daily operations. The owners and managers are good people. It’s nice to do business with them. They are flexible and smart. They have experience in software development and Agile. It’s a pleasure to work with them. I can’t comment on the developers.

Are there any areas Pragmatic Coders could improve?

It’s difficult to work with remote developers. They don’t fully understand our business. We work with them some but we try to keep it in-house. It’s not because they’re not good.

They were growing and hiring developers. Sometimes the people they provided us weren’t good enough. Those problems were solved. At the beginning the team wasn’t mature so the quality of each team member could vary. They’re good now, they're stable. We don’t see the problem anymore.