What do I do when my team leader is breaking my database schema with a release coming up?

Question

My team leader has this terrible habit of mucking with the database schema, and making changes that would cause severe breakage on the code base (without really consulting me on how the changes would affect the code base).

Normally, I would just live with it, but we have a deadline in 2 weeks and this has been happening ever since I started 1 and a half months ago. I was brought on, to speed up the development of the project.

Due to the deadline I am already putting in 60+ hours a week, and dont really have energy left to deal with this (I have tried in some ways already). We are only a 2 man team, and besides changing the database on a daily basis, he has not contributed much in the sense of actual development (coding).

Currently, I am feeling like I am doing all the work, plus having to 'fix' what he breaks with his changes.

How does one deal with this? I have already spoken to our manager about his lack of effort in the development department. He has been there 6 months longer than I have, but I have written 95% of the code when you exclude the 5th normal form database monstrosity he 'contributed'.

Any suggestions?

Post-mortem:

On Friday we had a discussion with manager, and I made my worries known. This led to a bit of confrontation, but overall I felt the manager was siding with me. So at least we have our data freeze in place now, let's see how it goes from here.

Answer 1

"Deadline is in two weeks; we need to freeze the schema if we're going to hit it."

Answer 2

You are going to have to be more forceful and make sure that soon (as in yesterday, the day before yesterday, or last month) you settle on a schema and move forward. There's no sensible way that you can continue to develop an app with a database that is a moving target.

Answer 3

You need to confront him and explain to him how his changes are effecting the code base and hence the project time lines. Convience him that he needs to consider the impact of his changes before effecting them. Also make him to agree in the presence of your manager to the fact that he will be responsible for any delays that he induces by this behaviour

Answer 4

Speaking to the manager AND the developer at the same meeting:

"Database and code changes need to appear simultaneously. If you change the database, you must also change and test the code base. Otherwise you are submitting broken commits, which is unacceptable if we are to meet the deadline. I will no longer fix code broken by your commits, I will simply back out the changes and leave you an email note because I cannot investigate and fix issues outside the work I'm assigned and still expect to meet deadline."

Much harder if you don't have a test plan...

Answer 5

If the team lead is not reasonable person (and he/she doesn't sound reasonable from your description of his behavior), talk to your manager and explain to him that you won't meet the deadline with the way things are going. Ask him to take a stand and make sure your team leader is aware of this by holding a meeting where the manager sets expectations.

You should also push your case regarding your team leader's lack of contribution to development. Both issues must be resolved to make the project a success.

Answer 6

You are going to have to enforce some restraint on your team, but that can be tricky to play in your position in it.

A useful way of tackling this might be adopt more rigorous documented change control. You can play this by insisting that at the moment ad-hoc changes are putting at risk your ability to manage the system updates in a way that doesn't have unforeseen, and deadline threatening, consequences (which is true). So insist that all changes must come with documentation showing the proposed change and the effects thereof on all other code and structures. You'll be amazed how much that will reduce the volume of changes that come through :-)

Answer 7

Have you held a retrospective with the team? If not, hold one. When you do, identify the unplanned changes (mucking with) to the database as an issue. Specify the cost to you and others regarding risk and quality of work life. Continually working 60 hour weeks is not sustainable. If you are not able to sustain your pace of development, you are not doing agile.

Also, are you doing TDD (test driven development) or automated functional/ regression test? If so, changes to the database should result in broken tests. This should help address the impact and identify the code that needs to be updated.

In this case, your team lead is not "too agile", your team lead is an "agile cowboy". Hold a retrospective, identify what went wrong. Prioritize it high, then address it during the next iteration. That should rope in your agile cowboy!!!