Team alignment: Objectives & Company Values Alignment
To improve collaboration across teams and ensure there’s no misalignment between team and company objectives and values, every quarter we check everyone’s objectives with each other and with their managers, to see if they’re still relevant to the business. If they’re not, new objectives are set up until everyone is aligned again.
This practice has proven extremely valuable for keeping people accountable for the impact they have on objectives that are actually being worked on. Performance Reviews Performance reviews are done every other month, again to ensure accountability for impact and to give everyone time to reflect before receiving feedback. Team alignment: Weekly Meetings People spend half of their time at work, so it’s important the other half is spent working with others. To this end, we’ve started having team meetings every week where everyone shares what they’re currently thinking about or working on – regardless of which sub-teams they are part of – whether it’s related to our current projects or not. This has created a variety of benefits including getting different teams coached by one another early in the process, helping us better identify blockers, gathering valuable insights into how things work across departments after they’ve moved on to another sub-team, and letting everyone more easily track what everyone else is working on.
However, this practice can be too rigid for some people’s liking – preferring instead to work at their own pace without the hassle of having to constantly update others about what they are doing. For these people it can have an adverse effect where rather than being helpful, unfocused team meetings turn into long periods of time where nothing is getting done or worse, taking away their momentum by forcing them to switch focus onto something completely different mid-task. This has also been affecting our effective utilisation of time as we spend more time in meetings than actually getting things done. So with all that in mind I decided to try something new over the last few weeks.
Towards the end of August I took over doing the team meetings and because it was clear that we don’t need to allocate an hour or sometimes more for our stand ups, retrospectives etc, I just did 30 minute meetings once a week. At first it didn’t go down too well with some who felt that this would be too short but apart from one person everyone else accepted that although it might not work for them at least they could see what others thought about it and if things went well perhaps think about changing their own meeting style in time. But obviously, if people are never satisfied then thinking about changing your daily practices is right out so you get used to them quickly enough even though they may not suit your needs perfectly.
It didn’t take long to realise that the 30 minute meetings were not enough either. When it comes to communication, I’ve always believed that too much is better than too little. This is because communication allows you to check your understanding of what’s going on or what you need to do next time or who said what etc. So I added a 15 minute stand up meeting for everyone at 9am every morning which are basically status meetings. We have our backlogs split into four stories so each developer talks about how far they have got with their story and whether there are any issues preventing them from making further progress. It also gives everyone an idea of where other people are up to so if someone has made no progress since yesterday then the whole team can discuss whether we need to talk to them or find someone else that can help.
Now as soon as something is done it goes into master and gets pushed out to all the other environments (a separate post on how we set this up). We also have a CI server running against master which builds our installer package and uploads it to our file servers. Once there, we run some client scripts that make sure everything is copied over correctly and create shortcuts for users. It’s very important you do all this because if people don’t get automatic updates but still want to use your product then you will lose them. Also each platform obviously has different ways of updating software so automating this saves you from having to write extra code for each one.
During this whole process we have found that you should really decouple deployment from release, if your release process is slow the only way to work around it at first is for developers to work on branches and merge into master as early as possible. This combined with having QA / Staging servers allows people to do their work in a more agile way and makes sure nothing breaks upon release. It also means you don’t need an army of system admins around burning the midnight oil waiting for a build so they can deploy it before everyone goes home (we’ve all been there).
