Capacity Planning Then and Now

Before I was working in an agile environment, my experience led me to believe that a Project Manager's main responsibility is resource management:

As a Junior Programmer, I learned everything I needed to know about what the system should do from my technical lead and project manager. "X has assigned you as the resource on task 27, you have 3 days to complete it"
As an experienced developer the tech lead/PM would ask me "since you are the resource on task 27, how long do you think it will take you?"
As a tech lead I actually was given a technical specification to read. After reading it, the PM asked me "who do you think we can assign to task 27?"

At most of the organizations where I'd worked, developers were considered resources on a project plan that the PM would assign to tasks. This sort of perception runs contrary to the "respect" principle as well as the "whole team" and "collective code ownership" practices.

How does it run contrary to respect if someone is thought of as a resource? Aren't all resources on software projects valuable? Not exactly. In environments with tight deadlines and few skilled developers, Project Managers often find themselves in a resource treasure hunt game. They will purposely schedule the "development phase" around the availability of that one "special" programmer who can do it all. In other instances, PMs will justify recruiting new talent for a specific project and keep all of their current hires on "maintenance" or worse.

I once worked at an organization where 80% of new work was outsourced to an ERP vendor and a large consulting company. Rather than train the existing staff, the company decided to hire and entire group of new developers to work on the new up and coming platform. Those of us who not fit a certain skill set (I imagine that was not bound to the company by a H1-B) where left doing maintenance. One Monday morning after I came back from a well deserved vacation, I arrived to a bunch of empty cubicles. 50% of our team was let go. The director of architecture said "we had to get rid of some dead weight". Is that respectful?

To address my second point of the XP practices, I think that it goes without saying that "collective code ownership" is about maintaining a constant flow of knowledge transfer. At organizations where developers are resources there is also a common practice of "module ownership" and that has proven to keep the truck number very low.

In addition to increasing risk, this managing developers as resources thinking also lowers moral. I mean how would you feel if you were passed up on a project that you really wanted to be on? Or that you were not assigned to the task you wished you could do? When the whole team participates, one is given the opportunity to choose the work one wants to do!

This proves itself to me every time a new developer joins our team and they are astonished that they are able to sign up for tasks as well as being able to design the system! I almost forgot what that was like until recently when a new developer was integrated into our team as part of a cross pollination effort. He knew that we were doing something the wrong way and hesitated to tell the team.

In passing, I overheard him complain about how the organization did not really take advantage of the more advanced features of Spring such as transaction management. I immediately jumped at the opportunity and said, "I am glad to see that you are familiar with Spring, it was just what our team needs. By all means, refactor the code into something simpler and get rid of anything you see that is unnecessary". The look that he gave me was priceless. It was a look of bewilderment... why? Because no one ever valued his knowledge or opinion. That's all it took, just a little respect and making him a true part of our team. Now I know how Spring XA works and I did not even have to read a book on it ;-)