Change Your Organization Diary Part Two May
Change Your Organization Diary Part Two May
Previous iterations:
7 May. Not dead yet...
The meeting with the client didn't happen. Environment problems are still rampant. Our velocity last iteration was zero.
I've gotten agreement from the architect who was previously handling most technical communication with the client to let me talk to them directly. We got approval from senior management. Tomorrow we're going to try to set up a phone call to introduce me, and then I'm going to once again propose that I fly out and meet face to face.
I have two and a half weeks to turn this project around before I start losing programmers. One of them talked to me today, saying he wanted off; I convinced him to wait to see if the increased control I now have will make a difference.
I've changed the goal from "deliver to the client's schedule" to "make the client happy" and gotten management buy-in.
Yikes, it's been a couple weeks since your last posting - has that client meeting been scheduled? How was it that by May 7 you had never even spoken to the client on the phone? Do you mean you've had contact with the hands-on Customer types, but not their bosses? Or have you really never had a real conversation with anyone from the client organization? --BillSeitz
20 May.
Nothing happened for a month and a half. I brought it up over and over again, but nothing happened. It was a weird denial situation. I would have discussion, we would agree that "something must be done," but then -- nothing would happen! Nobody seemed to care except me.
In the middle of that, we lost connectivity in our integration environments. We had no ability to test our code and we had a lot of code that was coming due. That caused some major thrashing and is why our velocity dropped to zero. (No ability to test = no stories marked 100% complete!)
There were some pretty spectacular communication failures going on. The client didn't seem to realize the problems that the lack of integration environment was causing. The company didn't seem to realize the problems the schedule would cause. No one clearly had responsibility for either of the problems, and no one would take responsibility. The people with the power to change it were so busy -- or so in denial -- that I could barely get their attention.
About three or four weeks ago, I put together a spreadsheet. It showed all of the stories on a single page. Prior to that moment, every PM had his own list of stories, but they hadn't been aggregated. It included estimates and used some fancy equations to quantize the stories into iterations with release dates.
At that point, our velocity was zero, but I plugged in a velocity of one. The result: the last story, due in August, would be delivered in September. Of 2009.
That spreadsheet got some attention, but not much. We started yelling "fire" together, but everyone else continued ignoring us. It's as if the house was burning down around us and people were settling down on the couch to see what was on TV.
On 18 April, I talked to the director of development here (my boss's boss) about simplifying the command structure. Basically, putting myself and one PM in charge of the project. He agreed, and his colleague on the PM side agreed, but nothing happened. So a few weeks later, I had the discussion again, this time with the people that are currently "in charge" of the project but are too busy to do it. That time, it seemed to stick.
During this, our continual efforts to shout "fire" got us into a special emergency session with top management. We said that the project was failing. "Ho hum." We said that the client wanted us to take on more work, but we couldn't, because our current schedule was full. "What!? Before you tell that to the client, talk to me first!"
Ah. The point of change. An executive sees money left on the table.
Now things started to happen. We again went to the director of development and his PM cohort, but this time with the current "leaders" of the project. We had a fruitless discussion about changing responsibilities -- but got enough of an okay that we just pretended there was on okay. At the end of that meeting, I mentioned that we weren't going to make the schedule. The director of project management said, "okay, come back to me with a plan that shows how we can accept additional work." I said, "I want to be very clear: it isn't possible for us to make it."
Action! Meetings are called. People rush around. I spent all of last week reviewing methodologies and plans for scaling up the team. Yesterday, Monday, we had an all-day meeting to review the options and come up with a schedule.
So we did.
We're adding fifteen people to the current team of four over the next six weeks. The rate of adding people was set by the client: they've hired some off-shore personnel and have dictated that we add them to the team. We're adding three people ourselves right away. Tomorrow, we'll have seven people. In a week, eleven. In four weeks, fifteen. Then eighteen.
What about the good Dr. Brooks?
Well, he may be right. Then again, he may not. Agile methods give me some tools that he didn't have... and even with eighteen people, I think my project is much smaller than his were.
Even so, my best prediction of the future shows us delivering two months late. That's an "everything goes smoothly" model, too, which seems unlikely with this client.
The plan is to split the team into three parts as it grows. The core dev team will continue developing stories in an XP fashion. Their job will be to focus on delivering planned stories, and nothing else.
A second team, the "SWAT team," will have the job of removing technical roadblocks. They'll be keeping an eye out for things that get in the way of the core team. Anything they see, they'll remove with extreme prejudice. In their copious spare time (hah), they'll work on supporting ad-hoc needs like defect reports.
The third team will be the consulting team. They'll engage with the client as projects start up. They'll produce the documents that are required and will help the client solidify requirements. Each project will have a "lead consultant," and as projects move into construction, the lead consultant will transition on to the XP team.
Every iteration, we'll allow some people to change roles. The SWAT team will be less stressful than the XP dev team, but less focused. The consulting team won't be as development focused. There needs to be some flow of people between the teams to keep knowledge flowing. On all teams, there will be pairing. Pairing will be the primary mechanism used for bringing new people up to speed.
I created a hopefully-not-too-complicated spreadsheet to model our velocity as we added people. I predicted that the SWAT team would allow the core team to be 80% efficient, even when it's increased to twelve people. (The other six would be on the SWAT team.) I said that existing developers would be 100% efficient (before the previously mentioned 80% overall efficiency is factored in), but new developers would be degrade performance by being at -25% for the first two weeks, 25% for the second two weeks, and then 100% starting on the fifth week. The offshore developers would be slightly slower because of infamiliarity with the environment: I had them at -25%, 25%, 75%, then 100%.
It's all a wild-ass guess. I have no real information on this. But it seems reasonable and I can measure reality to see if it matches my predictions. This is the model that shows us coming in two months late, at the beginning of October.
Is Dr. Brooks right? Or is possible to outwit fate? I'll get a chance to find out over the next few months.
PS: Our biggest problem is still communication with the customer. No change there; no real agreement on this side that it's a problem.
29 May. The expanded team is in place. It's coming along well... the SWAT team has been a great approach. I feel like individual members of the story team are going faster than they were before. The SWAT team has also been a good place to get the new people up to speed. It's only been three days, but things look very good so far. Stories are ahead of schedule, in theory, but that pesky integration still hasn't happened.
There's also good news on the customer communication front. We're starting to have regular conversations with the customer about schedule and scope. I had a good conversation with the guy in charge on Friday and we looked at our story list. Today, we actually started talking details and postponing less valuable stories.
If we are able to work a little faster than predicted, and if we can get a little scope reduction, then we'll have a shot at coming within a few weeks of the deadlines people are demanding. Things haven't looked this good in a long time.
next: ChangeYourOrganizationDiaryPartTwo
EditText of this page
(last edited June 27, 2004)
or FindPage with title or text search