Starting from scratch with a new agile team takes a lot of organisation and the self-inflicted pressure to get coding, especially for contractors, is very evident. Technology workers are used to sitting behind their screens, tapping away and getting on with what they do best. The monitor is their comfort blanket – their shield – and it’s a position that anyone in tech will recognise as default.
However, when you’re building a team from scratch, especially in the public sector, there’s a fair chance that the organisation may not be ready for you and your team on the day you arrive. This was my experience when I started in my first public sector contract, and it was a great lesson learned in responding to change – change from the norm.
So if on day one your team has no kit, software to use or even no desks to sit, don’t worry. In fact, don’t worry if on day five your team still has no kit, permanent location or software, because this will stop them falling into that default position of being glued to a screen, and avoiding eye contact with the strangers that now form their team.
When I started on this particular project, we had no kit for almost two weeks. Starting in a job without ID badges, access to the network, or dedicated work stations, left us with very little to distract is from having to talk to each other. And this precious commodity proved to be very welcome – it meant we had chance to get to know each other; a little about our backgrounds, who was quiet, who was the joker, who understood what we were about to embark on, and who didn’t.
Having to be chaperoned everywhere – through the gate in the morning, to the canteen and back, or anytime we needed to leave the building became an almost surreal flashback to school days when most of us recall being taken on trips and accompanied everywhere by a teacher. However, it really reinforced the idea that we are a group, a collection of like minds – a team.
As the days moved on and we slowly started to gain some independence, with ID badges and Smart cards to access the computer network in the second week, and finally, some laptops towards the end of that week, we had a shared sense of having gone through some strange, enforced induction and it was a great ice breaker for us to get to know a little bit more about each other and for me, as Scrum Master, to see how everyone reacted to the removal of the technology we all took for granted in previous roles.
It was interesting to see how the team worked around these obstacles and did their level best to make good use of the time. Meetings were readily attended, questions eagerly answered, and sketched out solutions to problems that were not even in our remit were offered up in an attempt for individuals to start feeling useful. Prototype work was kicked off on individuals’ laptops and everyone was tasked with the mission to learn the technologies we had agreed to push forward with. Even over the Christmas period, tasks were delegated and those not taking advantage of the holiday worked enthusiastically on their tasks.
One month on from the day we started, we finally had a permanent home, a dedicated meeting room, and joy of joys, a dedicated wi-fi connection, all many things we would usually take for granted. We were still awaiting our final kit and software, but did our level best to work around the limitations of the temporary kit. The experience gave me some insight into how the team worked at an individual level when the odds are stacked against them – which is remarkably well I must add.
It may be simple coincidence – another group of personalities may not have got off to such a good start – but I really think the disadvantages we faced in those first weeks did us a favour and set the tone for some good communications and team spirit.