I have been a consultant on a development team for nearly 2 years now and it has undergone a lot of changes in that time and I have witnessed changes in how the team views itself and its direction over that period. I thought I would post up a few posts on what I have learned over that drips. This post is a brief summary of the period and the big leadership mistakes I think happened. Hopefully if people I know read this they won’t be offended I posted it up.
When I joined the team it was for a small short term project to develop a simple WCF service. I was also tasked with a few minor fixes to the main product of the team. As the first few months passed I was consulted more and more on performance tuning the application and the architectural direction of the system.
During this period towards the end of 2009 I spent quite a lot of time speaking to people about the fact that the system we were working on was in need of serious work. It had evolved from systems used in the past and every change had been done in the quickest way possible, leading to a complete lack of overall architecture in the system and extremely tight coupling between components. There was no separation between data loading and business logic and it took a lot of time and effort to figure out how to make simple changes, let alone make them.
So at the end of 2009 I developed a proof of concept version of the system based on some basic design principles. I tried to remove the coupling in the old system where everything referenced every other class directly. I separated the logic of the system into what I believed to be clear roles and responsibilities. I tried to personify a component for each role: what do I do, what do I need to know to do it, what tools do I need to do it. I build interfaces to meet the companies movement towards a Service Oriented Architecture. Lastly I introduced the idea of Inversion of Control and Service Location to the system in order to help me create Unit Tests and Mocks. By Christmas of that year I had a working prototype of the major parts of the system, the data loading, the caching layers, the new model objects, the service locator, the service hosting and the configuration structure. People seemed happy with this and we planned out 2010 as the year we turned our old and busted product into a nice new shiny one.
When this project got approved people in the team seemed to be a little more excited about their jobs. The project was being worked on in Visual Studio 2010 rather than 2005 which the old solution was in. We were using .NET 3.5 and we made a nice new solution and started to move code over from the old solution and putting into the new solution to build out various parts of the system missing from the POC.
However, throughout the year as the new project became a bigger and bigger focus for the team it started to get a little more difficult to manage. I was, as I said before, a consultant on the team and therefore not exactly manager of the people working on the project. However, I was the main driver of the project and therefore people were looking for me for design and coding guidelines and for task assignments. As the person most knowledgeable about how we were building this new system, I was also tasked by the team manager with creating the project plan and working out how long everything should take. Personally I think there is a problem here which although a few people agreed with me at the time, the person in charge didn’t. A developer is a developer, a project manager is a project manager. I was doing both t this point and it didn’t work very well. They are both full time jobs and one person can’t do a decent job of either at the same time.
Once I had spent a few late nights making a project plan with the right number of resources on the project and the right inter-dependencies for the tasks, I was told that it was far too long, how could we shorten it. I worked through all the scenarios and eventually after it was decide that the best route was to de-scope the nice to have functionality, we had a project plan about 9 months long. This is where the second common mistake of a development team happened. We were told that our plan had been approved in terms of time and resources, but the things we had de-scoped need to be achieved at the same time. This is my second big lesson from the last year, there is no benefit whatsoever in having a plan which you have no intention of sticking to. It immediately puts your developers on edge as they know they cant make the date and it’s makes your whole department look bad that their project runs late.
Another problem Whig befell our team last year was that our actual team manager left around the time our original project plan finished a the beginning of September. This turn led to another common problem I find, a tech-lead was appointed by the department head but no clear boundaries were set for the role. Therefore the team now had two people assigning tasks and making decisions on the architecture. I as a consultant changed my focus to be a supporting role for the new tech lead. I helped him perform code reviews and imparted the reasons behind architectural strategies I had used in the design. However there are people on the team who didn’t feel the right appointment was made for whatever reasons. I personally feel that more support should have been given to this new tech lead. Promotion from within the ranks can be problematic as although the decision might seem clear cut to the decision maker, the people who are not chosen can easily be left feeling rejected and resentful.
The project is still icing along and is now in production parallel. There have been other things worth mentioning that have come out of the last year and I will add more posts about lessons I have learned and things I have seen shortly. I thought I would post this one first though as it will explain a bit of where the other lessons are from.
Let me know what lessons you have learnt about common mistakes managing a development team.