This post was originally published on my LinkedIn profile.
As Software Professionals we all strive to work for teams and more importantly organisations who work in an agile fashion. The reality is often different to what is sold, but I think the difference is the way in which we cope with change.
The Hut Group is a company which embraces change and its ability to thrive with change is a major reason why it has grown, and continues to grow, at a phenomenal rate.
Recently, a slow-burning project sprang into life over the course of a couple of weeks. The upshot was that the software development requirement was intimidatingly large, critical to the delivery of the Group’s largest ever single investment and constrained by hard dates. This is not an unusual prospect for any of us, we can all regale stories and tales of woe in this regard.
At the time, there were three Engineers working on the project – a lot of time had been spent on setting up the architectural plan and understanding the problem and code had been cut. This all felt as though it was waiting for something to happen, it was obvious it couldn’t deliver in its current guise, but there was a lack of drive and urgency around the whole project. Conversations were happening as though the decisions being made were final, but in retrospect, I’m not sure any of us believed that.
The new impetus had to be used to kick this beast into life.
It was clear that the team had to grow to meet the demand, but it was also clear that the new team would need shorter goals than the final delivery of the project over twelve months away. The first short-term goal was agreed, the goal would drive out the delivery of core functionality and force the organisation to prioritise only the critical requirements. The goal was to be delivered in eight weeks’ time.
The challenge of growing the team was helped by the fact that the work was greenfield and allowed us to use golden phrases like ‘devops’, ‘cloud’ and ‘AWS’. We were passionate about what we were building, it was interesting, challenging and put the team 100% in control of everything – selling this was not difficult. We initially aimed to grow the total team size from four to twelve. By the end of the eight weeks, it was fifteen. We met people we really liked and we overshot a little. The new recruits came via transfer from other teams at THG and people new to the Group.
During the eight week period it seemed that every few days a new member of the team was joining. We continued with our two week sprint cycle, our retrospectives, standups and showcases. I firmly believe that this is what kept us in control. The pressure of wanting to showcase new functionality every two weeks and the goal at eight weeks was key to the team retaining its focus. There was no time for anyone to be ‘the new guy’ – most people qualified for that badge!
I believe that it was the iterations that gave us the ability to manage all this change whilst still delivering. The iterations made us constantly strive for adelivery and the retrospectives that came with the iterations allowed us to change our process repeatedly as the team grew and some of our old processes became inadequate and less efficient.
The constant change of requirements, dev process and new people arriving was therefore a force for good. Not only did the team become bigger, but everyone within the team became more productive and happier. When an individual feels more productive, they’re happier, they’re more relaxed and they become even more productive – it’s a virtuous cycle.
To the world outside of the team, the increase in size was not immediately obvious (during the initial increase in size, we also moved the team to a dedicated space nearer the business owners – away from our HQ). The only visible change was the improvement of the quality and quantity of work in the showcase.
At the end of the eight weeks, the goal was achieved – there was the odd late night with pizza in the run-up and not every showcase went without a hitch but the goal was achieved and it was important that the team celebrated the achievement. Within the space of two months, the team had more than tripled in size, delivered a major milestone, was together and flying.
Before the bulb on the projector from the final showcase had cooled, work began on the next goal – in fact on the next four goals. It was important to continue to ride the wave as long as we could. The momentum of a team is so important. From a management perspective, we need to be vigilant that this momentum doesn’t come at the cost of quality – that’s why the dev process has to be be there, be strong and be followed. To truly be followed, it needs to be a process that the team feel they own, that they have complete control over.
It’s now over a month since the end of the first eight week goal and we’ll soon be reaching another goal. The dev process continues to be tweaked every two weeks and today, we’re working far closer to the business owners than we ever were in the first eight weeks. We all work hard to maintain the virtuous cycle. We’re not perfect, we are better than yesterday and not as good as tomorrow.
Thanks for reading this far, please share if you enjoyed the post.
I’m always looking to meet people within the industry and learn about others’ experiences. I also have opportunities within this team for Software Engineers with varying experience and specialities.
If you’ve any questions, comments or feedback or to enquire about working with us, just drop me a message or leave a comment.