Morgan's First Sprint of Spring

Last Friday was the end of Sprint 8 on the Morgan's Raid project. This was the first sprint of the Spring semester. The "closers" are a team of eight CS majors and our one Honors Fellow from Art. The team were selected from among the 25 developers in Fall's CS315 class. These eight were among the top students in the Fall, and not all were from one team. I am not loaded for running the project this semester, and so I had to limit the number of students I could take on to what I could comfortably manage in my regular assigned research time.

During Sprint 8, we crossed the 1000th changeset, and as of this writing, we're at revision 1037. We had a pizza party at the end of the sprint to celebrate, and I promised the team we would do it again on every order of magnitude. I wonder if Papa John's will still be having their $10 large deal when we hit 10,000?

For Sprint 8, we budgeted 80 hours, assuming each student would work 10 hours per week and that most work would be done in pairs. Unfortunately, I had forgotten about Martin Luther King Day when we did the planning meeting, and so we were actually overcommitted when one considers that we lost a working day. Still, the sprint went quite well, and I think the team did a great job of estimating their tasks, including difficult design tasks such as revising the raiding system through multiple paper prototypes.

Since we have a dedicated space (hooray!), we moved off of Google Docs as a platform for managing the Product and Sprint Backlogs and are now using a whiteboard and Post-It notes. I think the only feature we miss from Google Docs is the automatic updating of the burndown chart based on updated estimates of effort remaining. (This also gives me an incentive every two weeks to post our burndown charts here, so that I don't lose my digital copies.)

The other major change we made was to modify the Sprint Backlog format. In the Fall, teams broke down user stories into tasks and then marked their estimates of hours remaining after each working unit. Whether a task was not yet started, in-progress, or finished was implicit in the numeric value and slope. One of the prominent weaknesses articulated by the team in last semester's retrospectives was the need for more formal validation, and so this sprint, we have a backlog in this format:

User story	Tasks not yet started	Tasks in progress	Requires validation	Done

Formalizing the need for validation helped in Sprint 8, although in the retrospective, we realized that we needed more careful articulation of whose validation was required. With multiple product owners and tasks of varying technical complication, it was not always clear who was the appropriate person to contact. However, I do think that losing Monday to MLK day was a major factor here.

Outlook usability fail

I was sending out a meeting request through Microsoft Office Outlook today, and I got this warning message.

I used a comma to separate email addresses when I typed them. This is wrong, it is my fault, and I have to go back and fix it.

Outlook can clearly detect the problem, and the QA process revealed that people make this mistake often enough to warrant a specific warning. Yet, there is no way to make the tool actually fix this. Not only is there no "quick fix" button: you cannot find-and-replace within the "To:" field of the meeting request, so a user has to manually go in and replace the commas with semicolons. I guess that is the Microsoft Office usability engineers' way of training us to do things the Outlook Way (tm).

For the love of Morgan

On Friday, I had to leave the Morgan's Raid team meeting early to join up with my colleagues on the Future of Education Task Force. I stopped in the office today to get some work done and found this note on my door.

I had been a little down on Friday, and I remember saying as much to the team. Lots of work to be done, including a wicked problem for the Task Force, a chapter to write, a course to plan, and the anniversary of a son's birth to celebrate. The team was listening. Good people, these.

Students and Simplicity

I assigned my CS222 students to read the Manifesto for Agile Software Development and the Twelve Principles of Agile Software. They were to choose two of the twelve principles and reflect on how these are pertinent to them right now, as students of Computer Science. Most of the students selected this as one of their two.

Simplicity—the art of maximizing the amount of work not done—is essential.

From their responses, I got the impression that they know that their approaches from CS1 and CS2 are not the simplest ways to solve problems. However, it was not clear to me if they were searching for the maximum simplicity (as in, make everything as simple as possible but not simpler) or the delusional simplicity (as in, software development should be simpler). I will have to remember to ask them to reflect on this later in the semester, once they have learned refactoring and design techniques and gained experience working in groups on projects of more substantial size.