THE IMPORTANCE OF THE TEAM

THE IMPORTANCE OF THE TEAM

 

In the Product & Tools Department, we put the “team” before everything else. We believe that a strong team can move mountains - which is both fun and hugely rewarding.  As a manager of the Vaimo Products & Tools Department, I want to share what we have found makes a team work well together and most importantly, share some notes from our continuous journey towards better and better results. Just to get you up to speed - our Products & Tools Department consists of a team of five people with different skills and talents, who work together to provide Vaimo with the best new products and tools possible. 

 

I. What is a strong team?

In a strong team, people trust each other deeply. One part of this trust comes from knowing people’s personalities; for example, knowing how they will behave in a tricky situation. The other part of the trust-building is all about mutual respect for each other's ideas, suggestions, and decisions.

 

What I think truly characterises a strong team is the team members' ability to commit to each other, share a common goal and at the same time, use each other's individual skills to achieve the best result. Another characteristic of a strong team is the team members’ ability to cover for each other; for example, when a team member falls ill or needs help with a problem.

 

For us, the important part is to know enough about what the other team members are working on to be able to dig in and finish it when needed. The whole team should keeps tabs on what each person's responsibilities are relative to the end-result, which ultimately allows the team to reach its goals, despite unforeseen events.

 

II. How to grow a strong team?

Of course, knowing what makes a strong team does not automatically make one. It takes hard (but satisfying) work to achieve this. In the Vaimo Product & Tools Department, the main tool we use for growing as a team is “learning.” This learning comes in many forms, such as retrospectives, training sessions, experimentation and social get-togethers.

 

The most important learning tool for us is the “retrospective.” After every sprint, we have a 1 hour retrospective, during which we reflect and identify things we have learned or can learn from the last sprint. We start by everyone writing down things that went well or didn’t, things they learnt and things that still puzzle them (opportunities for future learning). After that, the meeting becomes an open discussion, where everyone contributes their point of view. Lastly, we write down action points for things we feel we can change, improve or learn more about. 

 

However, reflecting on past experiences has a limitation. One can generally only reason within the limits of one's knowledge or understanding. Retrospectives are a fairly direct approach to problem solving. Augmenting this with additional approaches to broaden our general horizon allows for much greater creativity when brainstorming questions such as "how to do things differently.”

 

In the P&T team, we have two regular activities to broaden our horizon. We have an Internal Training session every week and after approximately every 5th Sprint, we insert a Hack Week into our rhythm.

 

Our Internal Training sessions are a mix of specific product/tool training courses (including our own products/tools), architecture discussions, discussions about how we work, and bringing in new ideas from the outside world.  

 

Very often we like to listen to new ideas from the outside world. Mostly this entails listening to talks from conferences such as Velocity, RailsConf, Øredev, Craft Conf, PyCon, and JSConf, to name a few. The conferences deal with topics such as Agile Development, DevOps, Technical Practises, Software Craftsmanship, Refactoring, Test Driven Development, Continuous Delivery, etc.

 

While most topics are not necessarily new, there is still often something new to learn. After each talk, we discuss the topic and add our own experience and opinions. Every now and then, a speaker goes off into unfamiliar topics, such as Game Theory or Psychology, but these are usually the speakers that leave the biggest mark, as they add a fresh perspective.

 

Getting a different perspective offers a new way of describing, expressing or formulating an old idea, which can be hugely valuable for thinking about the idea. I remember back in school, in my English class, we were taught that language is the tool we humans use to think. I agree. Being able to formulate the same idea into different words adds a degree of clarity to the idea when thinking about it. 

 

The biggest gain from these shared Internal Training sessions, however, does not come from the exchanged knowledge itself. Instead it comes from putting everyone on the same page. These shared experiences become common reference points or a common language for the team to discuss ideas, problems and technical issues down the line. This reduces a lot of friction in communication, which is one the biggest roadblocks to building trust.

 

During our Hack Weeks we take a break from our normal sprints for 1 week and work on anything that comes to mind. Sometimes these projects are entirely new ideas, while sometimes they are experiments with our existing products or tools. Sometimes, individuals work on ideas, and sometimes there is pairing. Sometimes there is quiet hacking, while sometimes there are lively discussions. The biggest goal during these hack weeks is to have no goal.

 

Hack Weeks complement our Internal Training in a practical way. They allow taking an idea that sounds good in theory (or worked for some conference speaker), and trying it in our own context, with our own spin on it, and seeing how far we can go. Sometimes, the ideas presented are very vague and trying them out in practice adds the necessary clarity, so we can evaluate if the idea is useful to us at all.

 

Our Hack Weeks have actually contributed a lot to our products and tools in both direct and indirect ways. During one Hack-Week, around 70% of the code of one of our modules became unnecessary, after an architecture session spawned a new idea on how to do the same thing differently. Less code generally means fewer bugs, less maintenance, and less opportunity for misunderstanding the logic by others in addition to often being more performant. In this case, it was an all-round win.

 

Not to be forgotten, we also have regular face-to-face meetings because we are a distributed team (half based in Stockholm, half in Tallinn) and don’t see each other every day (not considering our short daily video chat). Meeting face-to-face makes pairing easier and certain discussions more effective, but we also make a point of having out-of-office get togethers, and simply spending time in each other’s company. Most often, this takes the form of team dinners, but the casual after-work hangout with a few drinks has been quite fun too. For us, hanging out together/spending time together is yet another way to gain a shared context as a team, to get to know each other better and to build trust.

 

In a way, part of being a strong team is being allowed to be a strong team. In fact, these two ingredients reinforce each other. Being allowed to try a different way of working empowers the team to experiment with what works the best. Some experiments don't turn out as expected, but for the most part, experiments are based on educated guesses so they have a big chance of actually having positive outcomes.

 

I’ve found that when a team experiments and becomes better over time, they show that they can be trusted to direct their energy towards becoming better. This, in turn, justifies the freedom the team has to experiment with. With a clear focus on improving the status-quo, the determination to do so, and the resulting improvements to show for it, there's a great foundation for a team that goes from strong to stronger.

 

 

III. What have we experimented with? 

Over the last year, we have run many successful experiments to figure out a better way to work.

 

We started by removing the frontend/backend distinction from our User Stories (the end-user doesn't really care). Each user story is now owned by the entire team and the members collaborate as necessary to complete the story.

 

At first, we created separate technical tasks under each User Story that were taken by individuals; but after the collaboration improved, we realised that this practise took too much effort and we dropped it.

 

We started with various automation and testing efforts, such as building a complete infrastructure for our Continuous Delivery tool inside Vagrant virtual machines. This made changes easy to test. Even though we tested manually at first, this environment meant we could test (including edge and error cases) without affecting our production deployment.

 

Later we thought that by automating our deployments we will save some time in the long run. We spent a fair amount of efforts automating our testing and deployments, and it really paid off. Now we simply commit (or merge) something into the default branch of our project and a few minutes later, if all tests pass, it is automatically deployed. In the meantime, the team has already moved on to the next story.

 

Today we only use Pull Requests to work on our products. It took some time for experimentation and understanding the concept at first, as it seemed a bit foreign, but now this is the only way we work. Pull requests neatly separate out the changes for each story and allow continuous code review, as more changes are pushed to the pull request's branch. The Definition of Done was adapted to require at least one other team member to review the code in the pull request before it can be merged. And this collaboration works so well, that even though this review rule is easy to break/bend, the team stands by it firmly.

 

Another experiment was inspired by the #NoEstimates movement - we tried skipping estimation altogether. Estimation takes quite some time to do reasonably well, and even if done reasonably well, very often it's not that accurate.

 

Instead, we try to split stories into smaller units, specifically units that we think will not take more than 1 day. If any story still ends up taking more than a day, we take the opportunity to evaluate our options. For example, during a sprint, we may split the story again and finish a part of it that provides user value on its own (however small it may be), and leave the rest of the work to a new story. Splitting stories is a very powerful skill that takes time to get used to, but with repetition one can become very skilled at it.

 

Recently, we have spent most of our time trying to leverage pair-programming (which is quite hard over distance), test-driven development (which is now our standard way of working) and refactoring to keep a consistent pace (and keep changes easy) with our ever-growing code base.

 

All of these experiments together have been a continuous and disciplined effort by the team to continuously become better at what they do. But, does it pay off?

 

IV. Results! 

When we recently got together all in one location to work on a prototype for a new product we wanted to launch, It was very clear how much this effort has strengthened the team over time.

 

The product is a What-You-See-Is-What-You-Get CMS editor for Magento, which includes content staging, content revisions, publishing controls, and access controls. All of this is available while interacting directly with the site, so the user can edit/see the content directly on the pages where it would eventually appear. 

 

The prototype required effort from the entire team, and everyone found a piece to work and collaborate on and eventually got the code out of the door. The automated deployment tooling meant that every small increment was deployed to a test site (without any effort from the team), where product managers and sales people (who had a big input on the requirements side) could test the new functionality and give feedback on it. As the feedback came pouring in, the team adjusted the prototype and the changes were again immediately deployed and available for test driving by the same people, who gave the feedback.

 

There was pairing, there was individual coding, there were meetings with stakeholders, there were experiments, there was a lot of feedback and in the end, there was a product (prototype) that no one expected. It was beyond everyone's expectation! 

 

During this single week, it felt like more code was written and more changes were done to that code than we did during the next 6 months on that same product. Of course, in reality, the next 6 months were about creating a solid product from the prototype, which is hard work; but either way, I think the team is what made this dynamic and productive week possible. For the following two weeks, the team felt psyched and energised and in fact, the experience has grown the team to the next level.

 

Conclusion 

I believe a strong team can move mountains. In Vaimo's Product & Tools department we put special emphasis on the team and focus on learning and becoming better as a team. The team continuously aims higher, and in the end, this is what I think consistently results in achieving unexpected outcomes.


Read the rest of my team's reflections:

Tobias Wiking - “Keep up with keeping up!"

Pierre Dahlström - "Vaimo’s Products and Tools department's work process in a nutshell" 

Allan Paiste - "We, the developers"

 

 


Comments