Did you see Dwayne Phillips’ post today, Adding People to a Late Project? Dwayne says:
Adding people to a late project only makes it later. We have known this for decades.
Especially in the article he refers to, it seems as if there might be no end to the number of people added.
Did anyone ask the people on the project if they needed more people? Maybe they needed to know which requirement is top on the list. Maybe they needed acceptance criteria for each feature. Maybe they needed each feature to stay put for more than a nanosecond. There is more than enough blame to go around for this particular project. Most of the blame has nothing to do with the developers and testers.
Now, if they had asked me what I would do, here is my plan.
- What is the most important thing people need to do to sign up for health care? Get a cross-functional team to work on that, get it to done, and make sure it works. Use reviews, acceptance criteria, release criteria, whatever it takes to finish the work. Timebox that work to one week. Make sure you have performance tests. Roll it out. (Oh, do not let people work overtime. Make sure they can keep to a sustainable pace.)
- What’s the next most important thing? Do that in the second week.
- What’s the third most important thing? Do that in the third week.
- Now you have a shot of understanding the architectural needs. Go fix the underlying architecture. Make sure you have unit tests, integration tests, database tests, performance tests, and oh yes, system tests. But the tests that are key are underneath the GUI. They will tell you more than any GUI-based tests. Yes, you must test the GUI too. But the under-the-GUI tests will tell you the performance.
- While you are fixing the architecture in week four, if you have enough people, you set a group of people to fixing the overall performance. I suspect if you fix the architecture, you fix the performance. If not, you buy enough server capacity to fix performance.
I don’t know the culture of the project. I don’t know how many people are on this team. Is it a program or a project? Did they have silos to start? Did they think they could use waterfall?
I empathize with the technical people on the project. They were and are the victims of poor project management decisions and poor management decisions. On the other hand, they could have coded defensively with many tests. Maybe they did. They could have tested defensively with many automated tests. Maybe they did. In that case, they are ready for this phase, the “other 90% of the project.” Because they are deep into the 90% Schedule Game.
I bet these people are smart enough to work themselves out of this, by using timeboxes. The question is this: Are the managers smart enough to let them?
