Middle Management

Um. Run away?

Assuming you don’t flee the death march in terror, and do find yourself in a leadership role, I would strongly encourage that you pursue using the Scrum methodology to get your project management under control. I had the good fortune to meet Ken Schwaber (Scrum guru) a couple of years ago, listen to one of his expensive lectures, and have dinner with him afterward, and I know his process was designed specifically for people in your situation.

Part of the beauty of Scrum is that, unlike XP and some other agile methodologies, it isn’t exotic. It doesn’t impose controversial practices like pair programming, and doesn’t require tremendous team discipline. It requires management discipline, but if you can’t get that, you have no business being there anyway. Therefore, it’s relatively easy to talk management into it, and it provides a high return on investment.

Here’s some basics. First, it uses fixed short iteration cycles of about a month. At the beginning of an iteration, the customer(s) and development team negotiate what will get accomplished in the iteration. Here’s where management discipline first comes in… first, they cannot DEMAND things, they must negotiate, so development can say no. Second, they cannot change iteration requirements in the middle of an iteration, without stopping the iteration and freeing development of responsibility for whatever promises were made. If you can just accomplish this basic iteration mechanism, you’ve made tremendous progress in predictability, AND getting customers out of development’s hair so they can work. And again, if management can’t control itself well enough to handle one month iteration cycles before changing requirements (or acknowledge that only so much can get done in one month), flee in terror.

The next thing is the daily standup meeting culture. Every development team should do this – have a meeting sometime in the morning, with all developers attending, so everyone can stay abreast of what’s going on. It should be short – if something takes too long to discuss, have a meeting outside of standup. Scrum has the peculiar idea of pigs and chickens at its standups – pigs (team members) may speak freely, but chickens (non-members visiting the standup) speak only when spoken to. So management/customers can come OBSERVE the meeting, but can’t talk! (the pigs and chickens thing comes from a joke about breakfast… chickens are involved, but pigs are committed).

But my basic opinion is simple – if you can get an agile process like Scrum or XP in place, your development WILL get itself under control. However, without management discipline to insulate developers from customer demands, it won’t work. And if management won’t do that, just get out.

Oh, and I should add that on my project, we use a sort of modified XP. The project is now four years old. We are on time, under budget, our code quality is high, productivity is high, we can plan requirements AND MEET THEM about a year out, and staff turnover is fairly low.

I credit this success to a few factors. First, layered iterative development. Large-scale planning is done on a yearly basis. There are two or three releases per year. Each release consists of six to twelve iterations of 2-3 weeks each. Each iteration consists of a controlled number of stories (XP terminology).

The second success factor is pair programming in shared, open workspaces. Developers don’t work in cubicles… instead, there are open clusters of workstations where all coding is done. Communication between developers is very high that way. This greatly reduces the cost of staff turnover as well.

A third factor is test-first programming. Unit tests are integrated into the code base, and tests are written BEFORE code. This makes large-scale refactoring possible, which keeps the code base clean and flexible. Refactoring and code quality maintenance built into the iteration cycle, and customers cannot cut into that time, structurally.

Finally, remember the words of Kent Beck in Extreme Programming Explained… there are four variables in software development – cost, time, quality, and scope. Customers/management control three variables, and development controls the fourth. Broken customers/management believe they can control all four (the situation you’re in now). Quality is the first to lose, followed by the others. Quality is not a good control variable. Controlling scope is the best way to control the process, and that’s what all the agile processes are about.