• Can you tell us about your team and what you’re working on?

Our team is working on a project for a telecommunications company. The product is a billing and provisioning system that handles all process flows from start to finish, through the entire process of service delivery.
We have three teams of developers, one QA team, business analysts, and UI/UX designer.

• What development tools does your team use?

Development: MS Visual Studio, MS Management Studio, MS Visual Studio Code, Git
Testing: SOAP UI, TestRail, SpecFlow
Building and deployment: TeamCity, Octopus
Project management and planning: Jira, Epicflow
Communications: Slack, Skype, Gmail

• Which programming languages do your developers code in?

For external connectors, we use C#. For defining business logic, we use our own language, Bella. And we use the Angular 5 framework for frontend development.

• What’s your development process and product life cycle like?

We break the development process into phases and the phases into sprints. Every feature in the system starts with a user story in Jira, which is described by the product owner and has reached a Ready for Refinement stage. After that, our business analysts ask the product owner some clarifying questions and make small changes in the user story. The next step is Scrum Poker. This is where we estimate all stories and update their statuses to Ready to Start.

Then we hold a sprint planning meeting, during which the product owner and team leads define the scope of work for the next sprint. During the sprint, we develop, test, prioritize, and fix bugs. On the last day of the sprint, we hold a demo for the product owner. Additionally, we send a list of bugs we didn’t have time to address given our priorities and the time available for bug fixing.
The product owner’s team then decides if it’s possible to release changes on their own test servers right away or if they want to provide a list of bugs to fix before the release.
After we release on their test servers, the product owner’s team can start testing on their end. We also prioritize and fix all bugs they find.
In the final phase of development, we run end-to-end testing, dry run testing, and performance testing. Once these tests have been passed, the changes are ready to deploy to the production server.

• What does your code review process look like?

Once our engineers develop a new feature or fix bug, they make a merge request to the master branch. Only team leads who conduct code reviews are allowed to do this. Engineers need a team lead’s approval to merge a branch into the master.

• How is testing done, and what kinds of tests do you run?

During the sprint, we conduct unit and integration testing. We also conduct automated regression testing with a one-sprint delay.
At the end of the phase, we run end-to-end testing, dry run testing, and performance testing.

• How do you usually deploy your new releases?

Our deployment process is configured in Octopus Deploy and is fully automated. We have a clear sequence of environments where deployment runs. For instance, it’s impossible to deploy to the product owner’s server until a release is deployed to our own test servers and autotests have been completed.

• Can you describe an average day in the life of an engineer on your team?

We try to avoid spending too much time on meetings. We also believe that context switching makes us less productive. That’s why we hold most of our meetings in the mornings and try not to invite too many people. An hour after our workday starts, our teams hold internal daily stand-ups where team leads gather information to discuss with the product owner. Stand-ups last no longer than 10 minutes. After internal stand-ups for each team, team leads and business analysts hold a stand-up with the product owner, which also lasts about 10 minutes. In the middle of the second week of the sprint, all teams gather for Scrum Poker. On the last day of the sprint, all teams hold a demo for the product owner. If we need other meetings, we schedule them for those who are interested.

• How many hours a day do you work?

Typically, we work 8 hours a day. We don’t think working overtime is a good idea. If we see that it’s becoming problematic to meet a deadline, first of all we try to convince the product owner to postpone the deadline and reduce the load. In most cases it works, so overtime happens rarely.

• What is communication with your partners like? Do you communicate directly or through managers?

Team leads and business analysts solve key issues together with the product owner. That said, we don’t want a team leads to be the bottleneck in a project. That’s why in every team we have QA engineers and developers responsible for certain issues. They also speak directly to the product owners. Also, when someone has completed a story they usually hold a demo for the product owner. So I can say that all team members communicate with product owners from time to time.

• What makes your company a special place to work? What are the perks and downsides?

I think the most important thing is the non-bureaucratic processes in the company and the relationships we build with our partners. Anyone who wants to take more responsibility has the opportunity to do so. There are several examples when a person came to the company as an intern and eventually became a team leader, which proves my point.
The atmosphere in the company also plays an important role. It’s awesome to be part of a team where people are so passionate about what they do. We always discuss projects loudly and emotionally, so we never get bored.
And free lunches are also a nice bonus.

As to downsides, I would say that the “I’m waiting for a task, give it to me and I’ll do it” type of engineers probably won’t fit our team.