Ats Diary Week One

Part of the AtsDiary.

28 February 2000

The ATS project started up again today. In initial meetings with the company liason (the same person I worked with on the first phase of ATS) and the in-house team member (the person I trained at the end of the first phase of ATS), I mentioned that I would be using PairProgramming. As expected, there were some resistance to this. The idea that PairProgramming increases productivity as a general rule (something I don't have personal experience with) wasn't really accepted. But for ATS, I'm the only team member that has intimate experience with the ATS codebase, so my explanation that PairProgramming is the most effective way to develop and transfer knowledge at the same time was readily accepted. More information in AtsPairProgramming.

This was a half day for me -- spent most of it getting caught up and preparing for the arrival of the other two contractors that will be working on ATS. Spent some time trying to set up the environment so the four of us could work as closely together as possible. The cubicles here are great -- practically real offices -- but they're poor PairProgrammingFacilities. I did the best I could (got out a screwdriver)... hopefully it won't be a problem.

One thing we did do today was discuss the AtsSystemMetaphor. We had trouble coming up with a good one -- perhaps because we weren't talking to users, or perhaps because we were constrained by the existing design. The best we could do was to say that ATS was like a bunch of warehouses. Users would pull objects out of warehouses, change them, and then put them back into warehouses. Warehouses, of course, are a metaphor for the database. They work for us because we already have a bunch of "warehouse" classes that take care of the relationship between objects and the database.

29 February 2000

Al and I visited all of the user groups today to make sure that the features we had planned six weeks ago were still appropriate. We discovered that the primary user group, who's needs we had almost exclusively attempted to address, had not yet used the application at all, although it had been available to them for over six weeks. Further investigation showed that they were still interested, but not likely to be using it for another two weeks. On the other hand, our secondary user group, who had been using an interim solution, is eager to use ATS as soon as it has the security features they need. We also turned up another group with similar needs that is also eager to use ATS once security is added, and learned of another group that is interested in ATS, although more for its contact management capabilities than its activity tracking capabilities. So far (2 March 2000), we haven't been able to get in touch with that group's manager.

To get the ball rolling, we generated UserStories for some of the security features that had been scheduled to be developed in this iteration. Then we took those story cards to the two new primary user groups. The first meeting went amazingly well -- ten minutes of gabbing, fifteen minutes of story discussion, five more minutes of small talk, and we're out of there. The manager seemed very impressed. So was I. The story cards focused the discussion well: the user, 'Mike,' flipped through them very quickly. "Yes. Yes. Yes. Yes. Maybe. Yes. Yes." The user wrote us one new story, and that was it. The story cards weren't entirely the cause, though; the meeting was focused due to the smaller number of cards and the fact that the manager had a half-hour deadline. I was impressed by the story Mike wrote, though: it was his first exposure to the concept, yet the story he wrote was dead on in terms of style and detail.

The second meeting didn't go as quickly or smoothly, but it still seemed very productive. We had visited this user, 'Thomas,' earlier in the day and asked him to us some stories. Unlike Mike, Thomas wrote his stories without the benefit of reading through the ones we wrote first. As a result, they were more like reminder notes than stories and we had to rewrite them as we talked. Thomas produced a large number of stories, though, and one of his coworkers produced a few as well.

Most of Thomas's stories weren't related to security, and in previous times I might have been tempted to remind Thomas that "these probably won't make it in," or even discouraged him from making non-security stories at all. This time, though, I had confidence that the PlanningGame would make sure that there was exactly the amount of work in this iteration that we could undertake. As a result, I happily accepted all the stories Thomas and his coworker gave me, which I'm sure accounted for Thomas' apparent happiness with the project when I left. Initial impression is that AtsUserStories give the users a feeling of empowerment and buy-in.

2 March 2000

The last few days have been spent converting the remaining requirements from the initial iteration plan into UserStories. This afternoon, we all sat down and started estimating the stories, so we can have estimates in hand when we go into the PlanningGame meeting that's scheduled for Monday (6 March). First, we estimated the risk on all of the stories. As I describe in AtsRiskManagement, we only put estimation risk on the story cards, so the risk is pretty much just a temporary indicator to help us estimate, rather than anything permanent.

Once the cards were sorted into low, medium, and high risk, we estimated all the low risk cards. That went smoothly. Then we got to the medium-risk cards, and things bogged down. My original plan was that we'd quickly go through the cards, estimate the ones that we could, and make notes to do SolutionSpikes? for the ones that we couldn't.

That didn't happen. We started out with most of the security cards, since the estimation risk there is all for the same reason: how we track users' access priviledges. ATS has pretty unique security requirements, so although some members of the team have experience coding security models, ATS' needs still require some original thinking.

As a result, when I asked for estimates, we quickly got dragged into a discussion of exactly what kinds of questions the security architecture would need to answer. This necessitated thinking about the user interface we would present, and led to a long discussion of the issue. As an example, here's some of the results of that discussion. Remember, these are issues the security architecture will be expected to deal with, not questions that we were trying to answer. (Rather, we were trying to come up with these questions!)

Given user U & project P, what access (R, RW, N) does U have to P?
Given group G, which companies have company owners?
Given group G & company C, who are C's owners for G?
Given group G, company C, and users a,b,...,z, make those users only the owners of C for G.
Given project P, what users have been granted specific access to P, and what access do they have? (Do not include mgrs or company owners that have access by default.)
(etc)

What happened, I think, is that we got carried into working on a SpikeSolution rather than just making note of it and moving on. There's nothing necessarily anything wrong with that -- it was a productive session and it's information that's definitely needed -- but the part of me that wants things divided up into neat little fenced-off areas would have preferred to go through all the cards first, identify spikes, then prioritize and work on the spikes in pairs. I think that would be a little more efficient. (In this case, it wasn't actually that bad, efficiency-wise, since the one developer hasn't started and the other one had left. Only the two of us most qualified to discuss the issue stayed.)

Tomorrow, we're going to continue discussing this issue and other hard-to-estimate cards. I'm going to try to focus on getting through the cards and just writing down spikes rather than discussing questions right away. I tried to do that today, too, but there was a tendancy to say, "no, we don't need to do a spike, I just need to think about this for a second and we'll have an answer." I think perhaps that needing to do a spike seems somewhat like a failure, an admission that you don't know everything about a part of the system you're supposed to be an expert on. I'm going to try to counteract this tendancy by asking for no estimates tomorrow, just spikes that are needed.

Note: I'm defining SpikeSolution as any research that's required for estimation, not just coding. Sometimes, just a discussion of the requirements or a review of the design is all that's needed. That's what happened today. I'm calling that a SpikeSolution, but I don't know if I'm using the term properly. It fits for me, though. AtsSpikeSolution contains more.

3 March 2000

Today we went through all of our medium- and high-risk AtsUserStories and identified SpikeSolutions that would allow us to reduce them to low-risk. In doing this, I revised my opinion of the purpose of an AtsSpikeSolution: yesterday, I thought of it as any research that's required for estimation; now, I think of it as any research that's required to reduce a risk that's due to an unknown.

I also learned to appreciate the value of keeping a story's risk on the card itself. In AtsRiskManagement, I initially said that I prefer having separate cards for each risk, not just a little notation on a story card. I thought of the risk indicator as just a little note to remind me that I couldn't estimate the story yet.

Well, today we had to provide time estimates on short notice (more below), and as a result we had to make estimates (in some cases, they were practically guesses) for stories we didn't really understand. At that point, I realized the purpose of the card's risk entry. It's so that, if you have to make and share an estimate on the card, you can remember that the estimate is risky. The story's a risk because you don't really know how long it will take to deliver it. This 'ah ha' moment came when I realized that we would not be able to spike and reduce to low risk all of our story cards, no matter how desirable that may be in an ideal world.

As for the AtsRiskManagement cards, I'll still be using them. But it doesn't seem appropriate to create them for UserStories. Rather, I'll create them for specific EngineeringTasks? that arise from the stories.

Today we also had our first taste of the PlanningGame. One of our developers has schedule commitments that prevent him from being in the office at the same time as the rest of the group for about 12 hours out of the week. Since I'm the only one with previous experience on ATS, that time would be pretty unproductive, at least in the very short timeframe we have. Another developer has commitments that will keep him away completely for about 4 hours out of the week. As a result, we got a sudden request to drop everything and provide schedule and cost estimates for various combinations of developers. The result was the AtsPlanningGame (round one).