Change Your Organization Diary Part Two
Change Your Organization Diary Part TwoStart with ChangeYourOrganizationDiary. See also ChangeYourOrganizationTactics.
However interesting this reading is, this section is getting too long.
10 June. Done with our first iteration with the expanded team. It worked out well. The SWAT team was a definite benefit. I think I would use try to use a SWAT team on XP project that involved a legacy codebase or had an issue with lots of ad-hoc work. We had 12 people total but it felt like an XP team of six. The six people on the SWAT team got a lot accomplished (fancy record/playback tool for disconnected integration testing, for one) and were largely self-managing. The SWAT team's tasks were generated by myself and the other XP coach.
In terms of meeting our projections, we didn't quite meet projections. Integration ended up going a day over due to a merge miscommunication with the tech support team. In terms of total effort, estimate accuracy, etc., things look like they might be okay. There's a few warning signals, which I'll watch carefully over the next iteration.
Yesterday was the first day of iteration eight. We spent yesterday fixing up the merge problems and planned today. I counted the merge issue as a new story, so it was officially the first story of iteration eight. :) We also shifted some people between the SWAT team and the story team. Two of the new people came onto the story team, bringing it up to eight people (and the SWAT team down to four) and one experienced guy from the story team swapped places with an experienced person on the SWAT team. We had a release go to QA today, and the SWAT team supports QA, so the person with the most experience with the new code was the one to go on the SWAT team.
The stress of the situation had been causing some pretty serious contention between the project managers and the developers. Now that things are returning from chaos I hope it will get better.
10 July. The end. I tendered my resignation last week, and today was my last day. I'm happy to be moving on.
Two weeks ago, we finished iteration eight. For the eighth iteration in a row, the team had stories that were partially finished. Their velocity was three, even though the total team size was 16 programmers. Even accounting for the unfinished work, the velocity wouldn't have been bigger than four. That's exactly the same result we've seen from this team from the beginning. Adding nine people had no effect. (Thank goodness! Normally, I'd expect to see a big slowdown!)
I was pretty upset about the fact that we had partially-finished stories because iteration eight was the first iteration that we didn't have third-party dependencies. We had total control over the iteration, and as a result we should have been able to bring it in on time. At the very least, we should have managed scope to hit our timebox. But we didn't make integration a priority, so everything seemed fine until the afternoon of the last day. Then work slipped. It ended up taking 120 more hours to finish that one story.
I should have done a better job managing this. In fairness, though, I hadn't been coaching the team for several months. All of my energy was focused on management issues. I had been spending some time trying to get senior management to nail down roles and responsibilities and I was managing the introduction of nine programmers from India. There was the perennial issue of massaging the schedule as well.
So at the end of iteration eight, I was pretty upset. I called up the PM and apologized for the slip and the next morning we had a post-mortem to discuss the importance of timeboxing. Then I calculated the metrics for the iteration and projected out a new schedule.
The projections showed us delivering in late March. The customer is demanding delivery in early September. That's a real problem.
I've known that the schedule was unrealistic for months, but I've had trouble convincing management of that. So when I saw these new projections, I was happy. The last time we had projections we didn't like, we reorganized the team and added a bunch of people. This time, I said to myself, people will finally address the problems head on.
That was naive of me. The problem here is that there is no solution. The company doesn't have an alternative to delivering the requested scope within the requested time schedule. It's not a contractual issue, it's a fear-of-losing-business issue. And the fear is so strong, it affects everybody's actions and thinking.
So on Monday, right before I left for the AgileDevelopmentConference, I presented the new numbers. The result was an unconstructive meeting which involved a lot of implied blame: I had made big mistakes in choosing our process. The biggest target was PairProgramming: "We don't have enough computers cranking code" was a common refrain.
I left for the conference feeling pretty unhappy. After that meeting, I felt that my willingness to admit problems and take responsibility was being used as a vehicle for other people to avoid responsibility and place blame.
I had already been having qualms about staying on board at this company. I had asked the director of development to hire a development manager to replace me, but that was taking some time. I left for the AgileDevelopmentConference with a decision to make: either resign immediately, or stick with it through September.
While I was at the conference, I had the opportunity to talk with GeraldWeinberg, a personal hero. (Note the many quotes from him scattered throughout this diary!) We talked at length about professionalism and how it applied to the work I was doing at this company. My conclusion from that conversation was that I wasn't being treated with respect by this company, and it was because I hadn't behaved professionally in the way I negotiated my contract or in the way I had reacted to an unrealistic schedule. Specifically, I should have renegotiated my contract when my duties changed, and I should have stood up for myself, resigning if necessary, when I first realized that the schedule was wrong.
I came away with the conclusion that I didn't have the ability to deliver on the schedule my company wanted or the credibility to change the schedule. The professional thing to do would be to resign.
So on my last day at the conference, I crafted my resignation letter. When I got back to the office last Monday, I handed it in.
I'm very glad I did. While I was gone, without informing me, the director replaced me with a new development manager. (Actually, this was the person who kept making the "we need more computers cranking code" comments.) I tried to go back to coaching the team, but I found out that I wasn't welcome in that role either. The new dev managers's vision of my role was as heads-down programmer. Making the decision to resign before I heard about this allowed me to retain my dignity.
When I found out that my leadership was no longer welcome, I recalled my conversation with GeraldWeinberg. I went back to the director and demanded respect: I would assist in any way possible to transition my knowledge and responsibilities to my replacement, and I wasn't here to be treated as a lackey. When the transition was complete, I would be moving on.
That was a good decision on my part. I feel like I left with more respect than I'd had for a while.
There wasn't much in the way of knowledge to transfer. My replacement didn't have many questions for me. I spent a couple of days crafting my final iteration status report, going over it in detail with my replacement and with the project manager. I'm glad I did: I think the project manager started to see, right at the end, what it was I was trying to accomplish and why I did the things I did.
Before I left, I resorted to my old organizational change tricks. I picked one idea, timeboxed iterations, and stressed it with everyone I met. The reason is that the new dev manager and the PM have a tendency to plan based on desire rather than measured reality. I figured that the one chance they had of success was to keep up the timeboxed iterations and regular progress reviews.
To be honest, I don't think it will stick. It takes some time and thought to calculate those metrics. It's pretty tempting not to do it when the news is bad. I expect that the team will devolve into a reactive mode of work pretty quickly. The new dev manager was already pushing for a one week delay to the start of iteration ten "so we can hit the ground running." He also proposed having a half-day or so done on stories before the iteration started so the velocity would be higher. This demonstrates a pretty poor understanding of the idea of timeboxing. Oh well. He badly wants to show progress, and I think he's willing to sacrifice actual progress for the illusion of progress. Timeboxing gets in the way of that. (Example: at the end of the last iteration, he explicitly told people to continue taking on new tasks rather than integration testing and marking "complete" the stories that were done.)
A couple interesting things came out of that last status report. Most interesting to me was that the number of hours worked on stories was way down. Pairing was de-emphasized in the last iteration, two more programmers were added, and overtime was encouraged. Despite that, the team worked 40 hours less on stories in iteration nine than they did in iteration eight. I'm convinced that it was due to the overtime and lack of pair programming. Pair programming encourages focus: you never see a pair frivolously surfing the web. (See other PairProgrammingBenefits.) Also, when people know they're working overtime, they don't use their time during the day as wisely.
And that's it. My involvement with the company is done. Although the project probably won't be a success, I count my time there as a success. The problem with the project is an unrealistic timeframe and unwillingness to share that fact with the end customer. I tried very hard to address that problem, but I failed on that one. If I were to change one thing about my work here, it would be involving the project management side of the organization earlier and more deeply.
But... I did have a lot of successes. I successfully introduced automated testing, automated builds, a culture of asking for help, a cohesive sense of teamwork, a supportive environment, measurement-based planning, pair programming, and timeboxed iterations. The first two will almost certainly stick. Pairing and timeboxing, probably not. The rest... time will tell.
I did change my organization. It was a hell of a ride, and one I hope not to repeat. I wouldn't recommend it to anyone else. My reputation is definitely mixed at that company: some people think I did a great job under difficult circumstances, and others probably think I ran a project into the ground. I think that will improve as people see that the problems don't magically go away with my departure.
What's next for me? I'm going to continue to do coaching and consulting in Portland, Oregon. If you're in the area, drop me a line. I'm usually available for lunch, and I'd enjoy meeting Wikizens in the area.
Thanks for reading.
-- JimShore
No more to come.
Although Jim did a nice job reorganizing the whole shebang in blog form on his site, at http://jamesshore.com/Change-Diary/.
See various questions inserted above with my sig. Great diary. One concern I have is that I don't smell a clear linkage between the problems/risks your projects face and the process changes you focus on. If my team was 50% project managers, and I had no reliable integration testing system, a slow/painful build process, etc., I don't think I'd be worrying about pair programming... -- BillSeitz x
Likewise as BillSeitz states, except more towards the customer end. Do your guys know what they're building well enough that you can get away with not having a customer? Or are you accepting the fact that the customer won't like version one, just so you can get something done; which may be valid, obviously it takes time to ramp up programmers, but I hear little discussion anywhere about the time necessary to ramp up a customer to the point where he can supply work for 20 people. -- WilliamUnderwood
EditText of this page
(last edited January 13, 2009)
or FindPage with title or text search