As a backend developer at Vaimo’s Products and Tools Department, aka The Products and Tools team, I often hear that other developers - whether it be in Vaimo’s own delivery teams or developers from other companies - are interested in how we work in the Vaimo Products and Tools team. So, here’s my chance to give a little sneak peek into the way we work and who we are to my peers but also shed some light onto the software development process for anyone else who is interested.
What we do
The Products and Tools department is responsible for the products and tools that are used by the developers at Vaimo to build our clients' eCommerce sites.
Our team currently consists of 3 developers, a tester and a product owner (who is our department head).
Our goal is to have a cross-functional team so that we could solve all the issues that we get within the team without needing help from the delivery teams who are working on specific client projects. This means that every team member should have a broad knowledge about software development in general but still specialise on certain areas.
The product owner in our team is responsible for the products which we as a team develop and maintain. The product owner is also responsible for prioritising issues and features that are connected to our products.
Our tester focuses on testing the development tasks that the team are deploying and is also helping to introduce the released products and tools to the rest of the company.
As a development methodology we use Scrum. Simply explained, it means that we time-box our work by 2 week Sprints, also called iterations. The main idea behind using the Scrum methodology is that we want to be flexible about what we do. Things change and we can’t possibly know everything we need to know to be able to plan ahead more then 2 weeks at a time. In software development there are too many unknowns and the only way of dealing with them is to be honest and not worry about foreseeing the future.
The main tool for us is the backlog - that’s how we know how our tasks are prioritised and see what we should work on next. The backlog contains stories with descriptions of issues or features. Before each sprint, the product owner prioritises the backlog by ranking what are the most important stories to work on. To be able to start a sprint, we as a team commit ourselves to a certain number of stories that we think we can manage to complete before the sprint ends. This number is based on previous sprints and the number of stories we have managed to complete.
So, how do we estimate stories? We have decided to do it a little bit different then some people might be used to. Instead of trying to estimate a story, we try to split the story until we think that we can manage to do the story in one day. Notice that I use the word “try”. Estimation is one of the most difficult things when it comes to software development. An estimation is always a guess but it also depends on what you are supposed to accomplish with the story. Some stories are easier to estimate than others. As a ground rule it is a matter of the team’s knowledge about the world that the story evolves around.
During sprints / iterations
During the sprints, the team members will pick a story from the Sprint’s todo list. One thing that we cherish in the team is collaboration. We think that it is better to work together as a team rather than working on our own. With experience, we have seen that collaboration makes a huge difference when it comes to finished stories and the quality of the final result. This can be seen as a given, but from my experience many teams don’t cherish collaboration enough.
Some of the tools that we are using to increase the collaboration are code reviews and pair programming. Code reviews mean that at least one other team member will review the code before it gets released, pair programming means that two developers sit together to come up with a solution. Both of these techniques can be seen as a time waste but I would say it’s the other way around. When it comes to keeping the quality high there are no better ways.
Another tool we use is test-driven development. This means that we write tests before we write the actual code. This has many benefits. For many developers that are just getting started with testing, they only see the benefit of having tests written as part of the code, but for us one of the most important parts is that it affects how we write the actual code. To make the code testable, you have to write the code in a certain way that will make it easier to understand and maintain. The bonus part is that you'll have tests that will give you confidence when you later want to change the code.
After 2 weeks of working with stories, all the stories will hopefully be ready to be released. Our approach, when it comes to releasing finished stories, is that we want to release them as soon as possible. We follow the concept of continuous delivery. What this means is that we always want to reliably release the stories that are finished. Features that are not released when they are done are just money wasters. By releasing them when they are finished, we will also quickly get feedback from the users, which is important for us in order to improve our code. We really strive to have a feedback loop as small as possible.
I definitely stuck to my word of giving just a brief overview of some of the most important things about who we are in the Products and Tools team, what we work on and how we do it. That is why, if you have any questions that you’d like to ask me, feel free to connect with me on LinkedIn or email me - firstname.lastname@example.org - and I will try to answer and help out.