Last time we looked at how things used to be within my development team.  This time, let’s look at how things are now and some of the improvements that have been made.

We now have 3 broad teams of developers, each team with its own focus.  Within the teams we still have many smaller projects in progress, often with just a single developer working on their own.  The teams are focussed on front end / user interface developments, back end / 3rd party integrations, and customer support.  We’ve introduced a variety of languages into the product – we now use Python, C#, Silverlight and Javascript instead of just sticking with C++. Some people have started to specialise within those teams and our user interface team now includes a graphic designer – we include “user experience” as a serious part of our process.

By splitting the developers into these teams (and putting them in different rooms) we manage to focus on all areas of our product.  As we saw last time, with everyone in the same room and no defined roles, we only managed to focus on the current interesting issue within the team (usually whoever had just phoned with a problem).

Our release schedule is more defined.  Partly in thanks to Johanna Rothman’s book Manage It! we realised that in order to challenge our failure to release every year, we needed to shorten our release cycle not extend it.  We now aim for a monthly service pack release, a quarterly feature release and a yearly major upgrade.

This change in release cycle forced us to address our build and release process.  We now run an automated nightly build via Teamcity.  This also allows our test team to always have something to test, rather than waiting months between builds.

Our source control also needed to change, and we got good mileage from a switch to subversion.  However, it recently became apparent that we needed more flexibility in our branching strategy to cope with the different team goals and release cycles, so a switch to distributed version control is well underway.  As we were already big fans of Fogbugz, we decided to try Kiln, which is based on Mercurial.

Fogbugz is the hub of everything we do in development.  We track every change to our product through a case in Fogbugz, every change is proposed, reviewed for acceptance, implemented and then tested.  Fogbugz produces the output for our release notes (which now accompany every release, with every change noted), and contains a wiki of all the really useful information we want to share as a team.

We now have a dedicated team to handle incoming support phone calls and email, so developers no longer have to do this.  Whilst Fogbugz did a great job of handling those incoming emails, it wasn’t structured enough for the support team to figure out how to use it effectively enough – a wiki was just too general to store the information the support team required.  They have now switched to using SuperOffice, which does have the advantage of being the same system that the sales team uses.  As a database of customers, their equipment, previous support issues and maintenance contract details it excels.  As a piece of software to use to drive your daily tasks (handling support) it is one of the worst combinations of technology and user interface design I’ve had the displeasure of using!

As well as adding a dedicated support team, we have also increased the number of people in our testing team.  With a daily release available the test team always have something to test.  They have also improved the way they test.  They have more representative hardware available and focus on finding the faults our customers care about.  They also now test whether our software will downgrade as well as upgrade.

As well as improving the hardware available to the test team, the hardware available to the developers has also improved.  Dual (or even triple) screen setups are now the norm.  We have laptops available for each person who wants their own, whilst we still have a few available to share for occasional use.  In fact we have a dedicated budget to spend on whatever equipment or software we need as a development team.  We now use Visual Studio 2010 or Komodo as our IDE with tools such as ReSharper, NCrunch and Visual Assist X available to help and are constantly looking at new ways of improving our development environment.

Our physical working environment has also improved.  We shuffled people around into different rooms to help keep the teams focussed.  We even managed to build a partition wall to divide the largest and noisiest of our rooms down into two smaller and therefore more focussed work areas.  Our tired, old, straight-edged desks that had served us well for 15 years were replaced with modern curved desks that all matched.  With a more consistent look to our desks, we were also able to add matching book cases, cupboards and storage space.  With the disruption of changing furniture we also took the opportunity to bring decorators in to repaint the walls and brighten our working environment.

We now have a budget for training.  This allows us to purchase almost any book we think looks interesting, but also allows us to purchase training videos, go to external training courses and attend conferences.  This year we’ve had people at DevWeek 2012, ACCU and Usability Week as well as regular sessions for the whole team to watch Clean Coders.  It’s not just having a training budget that helps with training, but a general increase in the importance of training.  We now run regular Coding Dojos to practice and improve our skills and look at other free ways of improving.  We believe that Practice is important.  We are also far more involved in the local developer community.  We always have at least a couple of us at the monthly Geekup meetings – watch out for me giving a talk at one in the future!

Over the years we’ve doubled the size of the team.  Whilst bringing in new people brings in new ideas, it is important that those people are at least as talented as the current team.  Our previous interview process was very hit and miss, and whilst it certainly isn’t perfect now it’s definitely improved.  We now put ‘juggling‘ at the heart of our interview process with a series of simulations to try and identify if the candidate can do the job.  We still keep the interview friendly and fun, but we do need to know that the person we are interviewing can do what they say they can.

Whilst we can be very proud of the progress we have made, there are still lots of areas we can still be improving.  Let’s look at those areas next time.