So it’s been more or less three years (actually 17th Nov) since I joined the Hut Group, and it’s not going to be all that long until I’ve been here longer than I was at IBM (although still a long way to go to overtake Atos). I’d thought I’d take this opportunity to look back over the last three years and reflect upon what I’ve learnt.
I joined the Hut Group because I was getting bored at Atos Origin. I was working on a project for a large government department and although some of the things we were doing were interesting, it felt like I was destined to work on the project for the long term. A former colleague, Tim, was at the Hut at Head of IT and he asked me to come over and help him sort things out. I turned down the initial offer, but eventually decided to take the opportunity. The main reasons were that I knew Tim, and I wanted to try my hand at web development.
I joined the Hut Group as a Senior Developer and worked on mostly back-end projects. I integrated with a flowers supplier (not a great success), wrote a backup payment system and made lots and lots of changes to our back office system. I also made a good few changes to the website, including replacing the password reminder system.
At Atos Origin I had a number of roles as a configuration manager and it seemed natural that I would attempt to sort things out in this area at the Hut as well. We use subversion and I used to police the developers to make sure that they were using it correctly.
During all of this the development team grew pretty quickly. We I started we had 10 people in the IT department, including the TA, Head of IT and support team. A new CTO joined us, and we went on a recruitment drive that hasn’t really stopped.
As the team got bigger I moved into a TA role so that we could provide some technical leadership to the developers. I worked alongside the Chief Technical Architect (James) and helped get some pretty major changes to the platform in. I also spent a lot of time improving our monitoring so we could tell when the platform was having problems.
About 2 years ago Tim decided to take a new role, so I became the Development Manager and later the Head of Development. Our current CIO (Gareth) joined shortly afterwards and under his leadership we started to introduce agile development.
Our original process for getting work into the team was for a business stakeholder to fill in a work request form which one of the team would look at and estimate the effort involve. We would group a few of these together and form a project to be delivered. This was the theory in any case. What actually happened is that the work request forms sat in one of several large folders on my desk and pretty much got ignored. What the team actually worked on was whatever a few senior people in the group decided was important. The process wasn’t very transparent and we had a tendency to start work and not finish it. Things were not great, and nobody was satisfied with performance of the team.
The first thing we did to more towards an agile methodology was to get control of the work coming in to the team. I went round all the business to talk to them about what work they wanted to be delivered over the next twelve months. These were all written on index cards and James, Gareth and I gave t-shirt size estimates to them all (S, M, L, XL) and fitted them on to a rough plan. We moved away from 15 developers meaning 15 projects on the go, and organised everybody into small teams. We recruited a number of tech leads to lead the teams and they worked with the teams to get the agile practices we want embedded into the team.
Things began to improve pretty quickly, but it became clear that the Tech Leads were struggling to balance the management side of their role with the technical leadership of the team. We already had a business analyst working with us, and he moved into a project management role and we recruited two more PMs. The PMs work closely with the business to understand their requirements and act as Scrum Master for the project teams. They basically make sure that the developers can concentrate on developing and they remove any impediments that stop them.
I think the best change we made was decreasing the number of teams. We ended up with 7 teams with a couple of people in them, and this caused a few problems. There was a limit to who people could pair with, and limited the amount of work a team could do. If anybody was on holiday, work basically stopped until they came back. Worst of all it was difficult to get the team to self organise and engender any sort of team spirit. We cut the number of teams down to 3, each with 6 or 7 people in them. We’ve kept these pretty constant for about six months and they are now very productive. The teams organise themselves (to a certain extent), and we’ve got a good spirit in all of them.
The final change we’ve made is to create a “Rapid Response” team. This team handles all the day-to-day requests that come in to the development team. These range from fixing defects, to delivering new pieces of functionality. We aim for a piece of work delivered by the team in 3 days or less. We manage the work of the team using a kanban board, with the business prioritising all the outstanding requests twice a week. The prioritisation meetings take about 15 minutes and we have some really good discussions about what is important to the business. We’re delivering on average 5 tasks a week and the business like it as they have very clear visibility of what the team is working on now and next. The best thing is that they can see things being delivered.
So what will the future hold? I personally think we will move away from delivering “projects” to delivering features. These will be smaller pieces of work that we can deliver constantly. There will always be projects to deliver, but a lot of what we do is already feature based and a lot of the time we use scrum and sprints to mark time.
The biggest change on the horizon is that we are recruiting a number of test engineers. These will work with the development teams to promote best practice and help us automate our testing process. We’ve done some work in this area, but we have a long way to go. I’m quite excited about some of the things we can do with tools like Cucumber to aid automated acceptance testing.
What about me? It looks like I am going to get more involved on the technology side of things. We have a number of interesting challenges coming up to make the platform scale to support the continued growth of the business. The good thing about the Hut is we can react quickly to new opportunities and making the IT do this is good fun.
