A team in trouble would probably say that they would very much welcome expert help – but would they really? Are they ready to face the brutal facts of the state of the project?

An important part of the psychology behind forming a team is the distinction between “we in the team” on the inside and the rest of the world on the outside. To some extent this is good: A team with a strong spirit will be able to handle any obstacle in the outside world. But in some cases it can backfire, when the team stop looking at themselves, but only look at the outside world to explain problems. In fact; when a team is in trouble, they will in most cases first find external reasons for the trouble.

The customer demanded a huge change, with a very tight deadline.

The architecture in this legacy system is so hard to work with that it takes forever to make changes.

The first one is external – the customer asked for a change, but what about the second? It might be that the system was recently handed over to the team in which case it is external. But what if the team has been in charge for maintenance of the system for a year? The fact that the legacy system that they took over had an architecture that’s hard to work with is external. The fact that they haven’t done anything to it in a year is at least partly internal to the team.

Looking deeper at the first example that might be internal as well. The change may be huge to the team’s standards, but if they had a flexible architecture and proper automated tests in place it might not have been such a big issue. If the team has worked in isolation for too long, they are less likely to see that their architecture is inflexible and that their testing is sub standard.

Bringing in someone new to such a team might be a painful experience. Someone coming from the outside, bringing experiences from other projects will probably point out the inflexible architecture and the lack of unit tests. Doing that is a delicate issue. On the one hand the team desperately need someone helping them to see the brutal facts that they are denying. On the other hand, the team will not be eager to get confronted with those facts, as it turns focus from external issues that are affecting the team, to internal issues that the team themselves can solve.

The Hardest Question in My Career

Several years ago, I was sent to a project that was in trouble. I soon found out that they were in deeper trouble than they knew. Everything was sub standard, but the team were just working along, harder and harder, to deliver on time. They thought that they would have to work harder to deliver. They didn’t realise that the problem was that everything in the project was sub standard. There were no clear goals. There were no clear requirements. There were no architecture. They had chosen the wrong language and platform for the problem at hand and had the wrong people without necessary skills on board.

It was a disaster waiting to happen.

At the time, I had recently joined the company I worked for (my company was partly guilty of the mess) and I didn’t really know yet how my new employer wanted to handle such situations. On my second day in the project a representative for the customer asked me for a private talk. He asked me the hardest question in my career:

Anders, can you please tell me honestly how the project is coming along?

Ouch. Should I tell him that it was a mess – and tell him that my company had failed? Or should I tell him that everything was just fine, like everyone else in the project had said?

I chose to tell the truth.

It was one of the best choices of my career. By confronting the brutal facts we were able to take the right actions to save the project. We basically restarted the entire project six month into a 9 month project with a non negotiable deadline. In the end, the customer was really happy with the work we did.

For those involved in the project however it was a very rough awakening. They had spent months denying to the stakeholders and even to themselves that they had a problem. Now they were confronted with the brutal facts. In just a few days they saw a new team move in to completely take over the project.

In some ways I do feel really sorry for the team. They did their very best. The problem was that they had been assigned a task that was too huge and too complex for them to master. That wasn’t really their fault, it was the management that had set up the project to fail.

Facing the Brutal Facts

Even though management is to blame for the set up of the project, the team is also to blame. They should have asked for help in time. They should have faced the brutal facts that they were falling behind the schedule. They should have stated clearly that the platform and programming language was too hard for them.

The team that takes over a legacy system with sub standard architecture need to face the brutal facts of the amount of refactoring needed – and communicate that to management and the customer.

Hiding in the Comfort Zone

A common strategy to avoid facing the brutal facts is to hide deeply within ones comfort zone. Typical signs of a team hiding is to find them using Visual Studio 2005 or 2008, trailing two or three versions behind. Of course they are using web forms without any kind of partial loading or client side scripts and do all the data access with stored procedures and DataTables. No jQuery, no MVC frameworks, no LINQ or OR-mappers. That’s state of the art technologies – if you’re still living in 2005. The problem is that it is now 2013.

Staying in the 2005 comfort zone is a simple way to avoid having to learn new things. Only to find out after a few more years that there are no longer any jobs to be found with those technologies.

Working as a developer means facing the brutal facts of an ever faster changing world of technology. It means to continue to learn new technologies to stay current. It means to ruthlessly inspect and adapt the team’s practices to continuously improve.

Face the brutal facts – or fall behind.