Teamworking
A team is like a machine. We can imagine it as a car, travelling along a straight road. Like a car, its engine needs to be designed and built to be bug-free. Its speed is the energy of any team member. The fuel is the passion.
In this article I’ll explore some good approach to making sure a team works effectively and with the right attitude. The methods that I’ll discuss could probably be applicable to any kind of team, however, in this post, I will be making specific reference to life in a tech team.
Cultural fit
Spending most of your daily time with the same people, every day, means discussing, accepting and sharing.
Writing code in a project with other people means we have to trust each other and our skills.
So how can we figure out if someone is the right person to work with?
Hiring someone in a team is not that easy: it means investing in them, spending time to let them fully immerse themselves in the project and in all the processes. Most importantly, we’d never want to break the team’s solidarity and happiness by hiring the wrong person.
When I interview a tech candidate in my company, I try to understand as much as possible (and in a very short time) if he has the right technical skills and if he can culturally fit our team.
In our company we normally have 4/5 steps: in addition to holding a technical interview, the candidate must meet the CEO, the Product Manager and other members of the team. When the interview process is over, we have a quick standup meeting to feed back and share our opinion with the other interviewers. Of course the prerequisites are the candidate’s technical skills, as if the candidate doesn’t meet our requirements, there is nothing further to discuss. If instead we are happy that all of our requirements are fulfilled, the discussion progresses whether they are a cultural fit.
Here’s the truth: it is not easy to evaluate the personality of someone in an hour or so, but if the most of us have the same impression, then we trust each other enough to make a decision based on that.
There are a couple of pretty funny questions we ask each other in each of these meetings: Would you go for a beer with this guy? or Would you chat with him while you were waiting for your flight?
Granted, they sound a bit silly, but these questions just help us to take a fairly abstract concept like “cultural fit”, and to make it more concrete or relatable, helping us to express our opinion and make a decision. Our goal is just to understand if we’d be happy to work with that person, and if that person would be happy to work every day with us.
Obviously, the candidate’s past experience is also pivotal in whether we hire them.
Just because a candidate used to work in Facebook, Google or any other top company, this doesn’t mean that they would definitely fit our team.
Most of the time, working in a small/medium company is totally different to larger companies, both technically and culturally. Indeed, within a smaller company, the team is more “compact” and the job position often requires more responsibility (and the ability to juggle between them). Also, with fewer employees, interpersonal interactions become even more important and so does culture.
Scheduling process
In the former paragraph I mentioned the importance of “being aligned” with the team’s processes. A very famous software development process used in many teams, is the Agile methodology.
SCRUM is an agile approach to manage projects. For the sake of simplicity, we will refer to any feature, bug, task or improvement which has to be implemented or solved in the project, as a story. There are several online tools to track Stories, one of these (and also a very famous one) is JIRA.
JIRA is really powerful and it has a lot of functions that I won’t explain in this article. Instead I want to talk about boards. In JIRA Agile we can create a board related to a project (i.e. iOS app) where we can track our stories. The board has to be divided in columns, which, in SCRUM, are normally these:
TO DO -> IN PROGRESS -> REVIEW -> TESTING -> READY -> DONE
The arrows in this diagram show the order and flow of work.
The process is easy: when a story is in TO DO, means that no one is working on it, and it is waiting to be moved in progress.
When someone starts to work on a story, it is moved to IN PROGRESS. By working in this way, other developers will see that this story has already been started by someone else. This communication is important as it means that we avoid the risk of two people working on the same project.
When a developer completes a story, he moves it to REVIEW. The REVIEW state means that another developer should have a look at that story checking the work that has been done, to make sure it is fully complete and correct. If it is correct, it will be moved to the TESTING column, otherwise it is moved back to IN PROGRESS.
Now is the time when we hand the story over to the QAs. They have to test the story properly, and if everything is ok, they should move it to READY. At this point, developers will can merge the story into the main (develop) branch, and then move it to DONE.
Some team have a couple more columns in their Scrum board: WAITING FOR REVIEW and WAITING FOR TESTING. In our team instead, we prefer to have fewer stages.
There are a few really important ceremonies that make Scrum extremelly useful. Let’s see them 1 by 1:
Backlog Grooming
Backlog Grooming is a meeting that normally takes 30/60 minutes in which the team prioritizes stories in the backlog. Prioritizing means moving the most important stories to the top of the Product Backlog. Stories at the top, will be the first to be inserted in the next sprint.
Sprint Planning
Sprint Planning is a meeting in which the team discusses and estimates stories at the top of the backlog, in order to put them in the next sprint. A sprint can be of an arbitrary duration decided by the team, but commonly it takes 2 weeks. In this period the team should complete all the stories inserted in it. Initially it is not easy figuring out how many stories the team can complete in 2 weeks, as it is not easy to estimate them. Sprint by sprint it will become naturally easier. There are different ways to estimate a story, one of these is by T-shirt size (.., XS, S, M, L, XL, ..). Personally I don’t like it. I do prefer numbers ;). A classic sequence to use is the Fibonacci’s (1, 2, 3, 5, 8, 13, 21, ..).
This meeting is extremely important to keep the team aligned on what are the next things to do, and how long they should take.
Daily Standup Meeting
In this meeting, every morning before starting work, the team members stand in a circle. 1-by-1 they say to the rest of the group what they did yesterday, and what they will do today.
This meeting has to be quick and shouldn’t take more than 15 minutes. Every member can talk for 1 or 2 minutes, ball is passed to next team member. This is exactly the reason why this meeting is performed by standing in a circle. Standing, people are more inclined to be 100% focused and to be quick on sharing their progress.
Sprint Review
Sprint Review is the meeting that takes place at the end of the sprint. Here the sprint is brought to an end and a member of the team explains what has been completed and what has been not, mentioning eventual scope changes or issues that they encountered.
Sprint Retrospective
Immediatelly after the Sprint Review, there is the Sprint Retrospective. The goal of this meeting is to raise anything that needs to be improved, in terms of processes, teamwork, etc. An interesting part of the sprint retrospective is the initial improvement ideation phase (time-boxed), in which every member of the team writes any good and bad aspects, related to the last sprint, on green and pink tickets. This includes: what went well, what didn’t, what they would change and what they are grateful for. Only a few companies do this properly, even though it’s essential in improving the way we work as a team.
At the end of the Retrospective, a few follow-up actions to improve processes and teamwork are set up for the next sprint.
Pair programming
Sometimes it’s really valuable to work in pairs on a feature or on finding a bug. While a developer is writing code, another can observe him, following his approach, suggesting different ways or eventually correcting him.
In my team we use to do pair programming when we have really big and important parts of the project to implement or refactor. In these cases, the approach used from the beginning will be foundamental, as it will affect the whole implementation. I stongly reccommend that you practise pair programming if you ever find yourself in situations like these.
Conclusion
Providing a happy environment is the most important thing for a team. Having defined processes and being aligned techincally as well as culturally, we can reach sky high results.
Remember also to give feedback to your teammates in both negative and positive cases. This feedback can be general, or specific. An example could be Ehi Matteo, you really did a great job here! or Ehi Matteo, don't you think it would be better to do this in an other way next time?.
BTW, I wish you the best in your team ;) !
Thanks to Harriet Ballantyne and Antoine Sakho for the review of this article.
Follow me on Twitter!
Cheers!
Note: This article has been reported also in the busuu’s blog.