Willards Xp Diary

Introduction

A bunch of programmers, a tight deadline, fluid requirements. This looks like a job for ExtremeProgramming.

Characters:

Willard (Me): XP advocate. Long-time programmer, but what I really want to do is Coach.

The Kid: recent college graduate. Learns quickly.

The Consultant: spent a lot of time in consulting shops, and it affected his vocabulary. Still a decent programmer, though. Very into plans, especially when laser-printed.

The Veteran: has worked at a host of companies, most of which you've probably heard of. Remembers every single thing they did wrong. Thinks XP or Agile would have helped in many situations. Actively picking up XP practices such as TestDrivenDesign.

The Project Manager: non-technical, but very interested in scheduling and estimating.

The Team Lead: closest thing to an OnSiteCustomer we have. Understands the entire scope of the project. Acts variously as Customer, BusinessAnalyst, and Manager. Good at setting Priorities. A huge believer in YouArentGonnaNeedIt.

The Customer: a somewhat-high-up in Big Corporation of America. Acts like his job is on the line with this project; it probably is. Occasionally drops by to reverse previous decisions.

The Story So Far:

The team started out (smaller than it is now) with just a few months to create a web-based application from scratch. There was a (reasonably slender) requirements document, which wasn't as complete or consistent as it could have been, but was enough to extract UserStories from. Everybody knew Agile was the way to go.

When the deadline arrived, the app wasn't perfect, but it demonstrated all the required functionality for the first release. The contract was extended. There was much rejoicing.

But there's no such thing as "the last deadline", so our story continues...

Tuesday of Week 14

We just had a very productive IterationPlanning meeting. Nobody called it that, but we:

have a bunch of stuff to get done by next week
split it into tasks
wrote each task on a TaskCard
grabbed the cards we wanted to work on
estimated each task
committed to asking the customer about unestimateable tasks
made sure we weren't overcommitted

I didn't plan the meeting, or run it, or know about it until today, but just by presenting common-sense XP ideas that everybody'd already heard from me before, I helped influence the meeting. For instance, it wasn't clear at the beginning that we would be signing up for the tasks we wanted to do; rather than make a big deal over the point, I just talked throughout the meeting as if we were obviously going to be signing up for tasks toward the end. And lo and behold, that's the way it happened.

It was especially gratifying to see The Consultant (who was running the meeting) put in a good word for Task Cards. His position, and that of the Project Manager, seems to be that in an ideal world, we'd have a complete work breakdown in MicrosoftProject, with deadlines a few months out -- but in the real world, we have tight and shifting deadlines, along with shifting requirements and priorities, so for the near future, this agile stuff seems to be working well.

Thursday of Week 14

D'Oh. I shouldn't have bragged yesterday about how well our groups meetings go. I've spend most of today in mediocre meetings.

Things started with a design discussion about an oddball feature -- something that has to happen on a regular schedule. People were arguing over two different approaches, which seemed to shift slightly each time a new person spoke. The Team Lead didn't like the simpler approach, and kept thinking of vague, scary things that could go wrong with it. Finally, The Kid pointed out that, whichever direction we ultimately took, we could develop the guts of the feature now using the simpler approach, and convert if necessary to the more complex one. I jumped on this, spouting something about "being able to defer the decision until we have more information" (which is actually a good idea, and one of the main reasons to DoTheSimplestThingThatCouldPossiblyWork). Others agreed, and thus the meeting was mercifully brought to a close in time for lunch.

Shortly after lunch, we had another planning meeting. The main thing wrong with this meeting was that we'd already had it, only with one or two of today's participants absent. This led to boredom, which led to interesting off-topic, tangential, and overly-detailed discussions, which led to two and a half hours of my life that I want back.

At least we generated a couple more TaskCards? out of it. And another bright side: the Team Lead closed by soliciting everyone's biggest fears about the project, to make sure we were addressing them. So it wasn't a total waste. I guess I only want an hour and a half back.

Monday of Week 16

Today the customer dropped a whole bunch of new requirements on us which basically amount to a complete change of direction. Oh, and they want it eight calendar days from now for a big demo.

Instead of being outraged or wasting energy complaining, we just looked at it as a one-week iteration. In our meeting to discuss the news, we wrote each of the new items on a card, started thinking about estimates, and tried to figure out whether the amount of work would fit in the time allotted.

I'm kind of proud about how calm XP practices have made us.

Monday of Week 17

Ouch. I keep telling myself that I should integrate more often than once a day -- tonight it's finally caught up with me. Everyone has to commit their changes for tomorrow's demo, I've got two people lined up behind me to integrate, and I'm sitting here trying to get things to run after taking The Kid's update. Sadly, he's already gone home.

So I finally get things working on my box, then get tripped up by some badly-named launchers in Eclipse (don't ask), so do a manually-selected commit. Then the next guy in line (The Veteran), who's already waited something like an extra hour because my integration was so slow, can't get the tests to even finish running on his box. I finally send him home and vow to commit from his box or die trying, which I do (commit, that is).

The final integrator in line also has a slow time of it, though not as bad as mine or The Veteran's. I get to show off my mad testing skills by re-fixing an overspecified test (it cares about how some things are ordered) to be rightspecified (either order is fine).

Eleven hours is a long time to spend at work, especially when the last four of it is spent integrating. Still, we know that at tomorrow's big demo, the system will (a) work and (b) include everything we've done up till this afternoon.

Friday of Week 17

The Big Demo went well, though most of the developers weren't there.

Monday of Week 22

Another Big Deadline is upon us at the end of the week. Rather than focus on that, though, I'd rather mention a few interesting things that have happened in the past month:

What with the holidays and all, each of us took about five days off at the end of the year, but they weren't all the same days. One day when I was out, two of my teammates grabbed big chunks of a task I was working on and did them. Nobody felt any sense of territoriality, or that they'd be stepping on my toes, or that it would give me an unfair advantage to do "my work" for me, or anything like that. They just didn't have anything else to work on, and considered my plate very full, and took over the tasks. (It should be noted that the tasks were easy to parallelize because they're shotgun-like: do basically the same thing in a number of places in the system.)

I was surprised when I came back in a few days later. I wasn't sure how I felt for a little while, then I realized I felt great: my burdens weren't mine alone, my teammates did what was best for everyone, and there's no web of weird unspoken assumptions that kept them from doing the right thing. It was kind of Collective Task Ownership.

In a separate incident, a chunk of work turned out to be larger than a task ought to be, and similarly easy to parallelize. We were coordinating who was to do what after a standup, and I thought to myself (or possibly out loud) that it would be helpful to have separate cards for all the subtasks. I didn't give it any more thought, but the next day when I had a question about who was doing what, a teammate took me from desk to desk and showed me the cards she had made up and distributed to the people working on the tasks. The concrete, physical cards on concrete, physical desks did in fact make it much easier for me to grasp who was working on what, and therefore figure out who I needed to talk to.

In case you haven't figured it out yet, I really like this team.

Tuesday of Week 29

Inspired by RonJeffries's recent articles, I implemented my first BigVisibleChart. The problem: we're in bug-fixing mode, and I wasn't feeling much of a sense of progress. This led to a lack of motivation, which I sensed was leading to an actual lack of progress. Ergo, the Big Visible Bugs Fixed Chart, which was big, visible, and showed a green bar representing the total number of bugs fixed to date, with a red bar stacked on top of it representing the total number of bugs outstanding. (There are plenty of other categories for bugs to be in, but none of them are either (a) large or (b) relevant.) I took a few minutes to grab some historical data from last week, quickly grabbed the data for today, and after a few more minutes with some markers, it was up on the wall, staring us in the face.

Wednesday of Week 29

Inspired by I know not what (fear of visibility?), the Project Manager removed the BigVisibleChart from the wall, folded it neatly in four, and left it for me on my desk.

Have you asked the Project Manager's reason?

(OK, I'm not the world's most consistent diarist; if that's what you want, try Samuel Johnson.)

Note: It would be nice if Wikizens could let this page progress as is. This makes for a very interesting XP implementation test case history, and we don't have nearly enough of those. Let's don't be so quick to delete and just see what develops, hmm?

CategoryAdoptingXp