DEV Community


Group project time - javascript in a bootcamp scrum team

jennymegan profile image jennymegan ・3 min read

The past fortnight has been Javascript fortnight. Not that anyone alive ever learned javascript in a fortnight. Let's just say we put our toes in the pool.
It was also the first point at which we had to work on a team project. We've learned the theory of Scrum, we are all accredited scrummasters. Now we get to practise.
The task was relatively straightforward. We were building a javascript game. There are eight of us. We were to work as a single team.

My takeaways from this week are as follows:

  1. Git auto-merge is a privilege

In our solo projects, it was very rare for one branch to conflict with another when merging. Lovely. Now, with 8 of us - mostly programming in pairs - auto-merging became a thing of the past.
I miss it. Having said that I do sincerely hope that as we get better at structuring our workload and stop poking at tasks ahead of time, we'll have less conflicting code and an easier time sorting it out. We seriously underestimated the amount of time it would take to do the reviewing of code and the merging of branches: every day is a learning day!

  1. More is more, until it's not

Working on a project solo gave us complete control and complete responsibility. One the one hand, empowering, on the other hand, terrifying if you couldn't work out a gnarly problem. (nb. of course we can ask for help and advice but it's on us to do so).
Having the freedom now to pair programme individual tasks meant that you had two heads working on it; and as we're all learning at our own rates, often you'd tap into the other person's knowledge and sort out the error much quicker. Three people worked too; especially if the two of you had written an in depth piece of code and could no longer see past it. A third person "flying by" would sometimes pick up structural issues.
More then three in a zoom room and things started to go awry. Zoom likes to arbitrarily mute people when someone else is talking. Sometimes you lose half a word, sometimes you're just not heard at all. Some people felt totally overwhelmed by the number of bodies watching them. More people meant more dissention in syntax style (which bit us on the behind when we needed to consolidate code later).
There were even times when the entire team was asked to make a decision on something; and rather than making everyone feel included this tended to make everyone feel isolated when only a couple of voices were heard.

  1. Personal ambition is the enemy of team health

I saw a copy of Nike's famous "10 Maxims" recently. One of its points expounded the "danger" of personal ambition. This didn't make immediate sense to me, but once I overlaid it on the team based experience of this last week, it became very clear. Some of us came into this off the back of two solo projects which had gone well: been completed to deadline with all stretch goals reached. Not all of us work at the same rate, and not all of us place the same weight on different parts of the job. Someone who is dead set on finishing quickly, because that's their personal goal, will be a source of frustration to other team members who want to take their time over the design and layout of the game. And vice versa, someone who sets great value on the "look" of the game and can lose hours moving things back and forth will be a frustration to someone who would prefer to spend that time refactoring code.

  1. Communication is even more important than you think it is

and this holds true for technical stuff (like all of you agreeing at the start whether you want to use camel or snake case) as well as personal stuff - like not treading on people's toes when they're halfway through a task and you think you might know better, or checking in on a team member who has been particularly quiet that day.

  1. Come sprint review you'll be pleased to be part of a team

Presenting work solo is sometimes bone-chillingly nerve wracking: presenting as part of a team gives you the chance to hghlight the good work donw by others and feel proud to have been a part of it without the underlying guilt about potentially "showing off".

The next fortnight again holds a team project although of a very different nature: watch this space.


Editor guide