What evidence can you share that demonstrates the impact of the engagement?
They did quality fairly well. I think if we’d tried to do what we did in a bank, it probably would’ve taken two years. There were some issues on the frontend that should’ve been caught between deployments, which caused us to be a bit more hands-on than I would’ve preferred. Things occasionally got lost in translation or documentation. More importantly, though, they were willing to work to get to a point where the quality was what we wanted.
How did Byteridge perform from a project management standpoint?
Byteridge didn’t generally work in agile, but when we started out, we decided that it made sense for us to work in this way. Their lead developer handled that, and my side took up the project manager role. The rest of the team members on their side were developers.
I don’t think they had a contextual understanding of what we were building, which required more investment from my side to explain the concept, but they eventually got it. This wasn’t necessarily efficient, but it was more efficient than the alternative. The person we work with daily right now definitely understands the product.
There’s room for them to improve in terms of project management and the more administrative side of things. They did better once we moved to agile development and didn’t have to handle project management.
What did you find most impressive about them?
They’re very smart. For example, the lead developer that we worked with was able to understand the API and the integration that we needed to do, and she did it correctly. She worked through a couple of hiccups along the way, but other than that, she was able to figure it out.
I can’t speak enough about how hard they work. I think where they may have lacked in the contextual understanding or the initial quality outputs, they made up for twice in terms of how hard they worked. For that reason, we went back to them for the support phase. We know that they care about what we’re trying to do and like to learn the type of stuff that we’re doing. It was an engaging project for them as well, and as a result, they put in the hours to build a complicated application.
Are there any areas they could improve?
This is feedback I’ve given them, but I recommend having a preliminary workshop with the developers, especially for greenfield and startup projects. This gives everyone a common understanding of what the overall goal of the application is. Rather than just coding, they can think about what they’re writing as they’re going along and perhaps come up with some process-level improvements.
When we were trying to implement the high-fidelity wireframes in the code, both of our teams came across some internal communication transfer issues, and we came together and fixed the issue. Their improvement along the way speaks more volumes than being perfect from the start.
Any advice for potential customers?
Do an in-person workshop and invest 1–2 weeks ahead of time. With Byteridge, you may need to be closer to the project management side of things than you were anticipating. Don’t just completely hand over the project; have a product owner or project manager.