Teamwork makes the dream work
Working as a team a.k.a. “teamwork” is necessary in order to improve the development lifecycle in software development of a big project. Having a team that understands each other and commits to the same result is a big leap forward in getting your software developed and shipped. Most importantly: you will get happy customers at the end of the trip.
However, often one big question remains… How do we maintain our high standard about teamwork, when the project stretches over multiple years with people joining and leaving the project? Let’s dive into this matter.
Communicating as a team
When working on software as a team, clear communication is important. As the video shows, even simple tasks might look difficult depending on how someone interprets them.
One way to challenge miscommunication is by using a set format of communication channels that you use within your project. For the communication about stories in our software development projects, we use Jira. In that way, all the communication about a certain topic stays within a “ticket” in an effort to rule out miscommunication.
People want to be included, we are curious and look for new things all the time. Just like in real life, we want to know as much as possible about what’s going on in the development lifecycle.
Having everyone involved in decision-making boosts interest in the project and motivates team members to think about possible ways to improve the application for a client, while also feeling respected about the work they deliver.
Keeping the client involved is key! When your client actively knows what’s going on within the project, they will have a much better understanding about the inner workings. This will ultimately help with the realisation of the project as the client will know at any time what to expect. Linking back with the client from time to time will make sure that there are no unexpected surprises when finishing the project. Involving the client in the relevant Demo’s will make sure that there are no unexpected surprises when finishing the project.
Using feedback to improve teamwork
When focussing on teamwork, it’s important to know what’s going on in your team. Making sure that everyone is happy with the tasks they are doing will help the whole team in achieving the end result that everyone wants.
In our Flemish government project, teamwork is key. We have certain measures set in order to create a feedback-loop to assure that everyone is feeling comfortable and giving them the opportunity to talk about things that might not be right in their opinion.
One-on-one
One-on-one talks with a cup of coffee make sure that everyone has their moment to talk about the project and express their feelings. We often reflect on the past month and look for solutions for problems that might have occurred.
An important goal to achieve with one-on-one talks is to get to know each member’s personal goals and try to map them on the goals of the project. Merging these goals will give an increase on multiple levels. While the project makes great leaps forward, the team member will be able to pursue individual improvement, making teamwork a lot easier.
The Retrospective — Work as one, reflect as one
At our Kaleidos project, we include everyone at making decisions about the finer-grained scope of the project. This also shows up in the planning that gets done within the team. The planning is not done by a few people but by the whole team, code is reviewed by anyone of the team, no matter how experienced the person is. This once again creates involvement within the team causing big blocks of software to move forward as one unit.
Everyone is happy most of the time and the project hits a solid 10 on the teamwork-meter. Hoever, it’s not always roses and sunshine. An essential step to improving teamwork is reflecting on the last sprint and looking for things that you, as a team, can improve on. The first step in improving the work you can do as a team, is owning the things that go wrong. Once you know what’s going wrong, you can try doing incremental improvements in order to make progression.
Call to action
When there are issues after moments of reflection, an important step in the process is to write down some call to actions. Sadly enough, problems don’t solve themselves and need to be handled.
In our team, we have had some issues while traveling towards the path of great teamwork. One of the steps we took was to add call to actions at the end of every retrospective. We copy those to the sheet that we fill in at the next retrospective, making them a point of interest. This way, we always check if they are solved or might still remain there.
Celebrate
Lots of teams might forget this: you should take time as a team to celebrate the achievements that were reached after a full development cycle. As a project lead, you could hand out candy, for example, to celebrate this achievement. This will improve the cohesion of the team, bringing joy and excitement to the table.
On a bigger scale, you could work towards goals where the team for example has an internal teambuilding activity when certain big milestones get hit.
I’ve seen this work in other teams where they would go Lapland when certain milestones were hit, unlocking extra surprises when even more achievements got completed. Hopefully, we can do this to someday!
Teamwork booster — Great teams swarm
We use principles of Extreme programming together with a pragmatic approach of Scrum to make sure our project moves forward at a constant pace. Within the Kaleidos team, we do multiple pair-programming sessions within the team in order to spread information quickly over multiple members. This makes sure that the correct principles are used and shared when someone is not comfortable (yet) with those.
On Fridays, the team comes together where we spend the afternoon swarming on issues that might be blocked at the end of the week. Gathering a bunch of experienced and new developers together causes for weird and funny moments, while also solving the issue and strengthening the bond between the team, creating a real teamwork environment.
Kill your babies as a team
In software development, the client is like a sailboat: when wind changes the boat has to adapt with it. When the requirements of a software application changes, it’s the task of the team to adapt the boat to make sure it keeps sailing.
This might mean however that code that you’ve written yesterday, might be outdated today and needs to be removed. This is not easy for every developer. There are developers that treat their code like a baby and don’t want to get rid of it. Together as a team you should dare to delete that code when it might not be the best fit anymore for a solution. There will be a point in your career where it’s time to move on from code that is considered dead.
Pragmatism
In our project, we plan our work in sprints of two weeks. This would mean that our board should be empty at the end of each sprint. Does that ever happen? Of course not. And here is why.
The planning of a software sprint should be done pragmatically. You can’t technically finish everything completely within the spint. This would mean that at the end of the sprint, there is 1 person left writing the last line of code for a functionality just the last second before the next sprint meeting starts.
As that one poor soul is working his hardest to reach the deadline of this sprint, there are seven other team members that might be watching Youtube video’s because their work is done. Key takeaway: Don’t be a fool, use some common sense when it comes to “finishing a sprint”.
Conclusion
Teamwork takes time to reach its peak moment. When you work together, take the time to reflect on the past, you will eventually reach productivity levels you might only have dreamed of.
Remember, the whole is greater than the sum of its parts.
