Having reviewed the various retrospectives from Sprint 1, I thought it reasonable to write my own retrospective to highlight some of the issues and changes for future sprints.

Specifications

Several teams submitted PDF versions of their specification whereas my intent is for each specification to be included in the project repository as a plain text file formatted using reStructuredText (RST).

I’m probably to blame for this confusion because the expectations weren’t spelled out clearly in the submission instructions. (Note that I have not penalized any teams for submitting their specification in another format but simply requested that they use the provided template instead.)

To rectify this issue for future sprints, I’ve created a more detailed description for the specification, including how to submit it using a pull request (and putting it in the doc/specs directory in the project repository).

Pull Requests

Several teams expressed some confusion about pull requests, which may or may not have been resolved over the course of the sprint. A pull request is a solicitation for a project’s maintainer to accept a change from another contributor. In some cases, the pull request is accepted immediately, without any modifications; more commonly, though, the project’s maintainer reviews the proposed change and requests modification prior to accepting (and merging!) the pull request.

“Making a Pull Request” provides more information about pull requests in Bitbucket. I recommend reviewing that tutorial for additional details regarding the process, but the general steps are as follows:

  1. A developer creates the feature in a dedicated branch in their local (clone of the) repository.
  2. The developer pushes the branch to their fork of the repository on Bitbucket.
  3. The developer opens a pull request via Bitbucket.
  4. The rest of the team reviews the code, discusses it, and modifies it.
  5. The project maintainer merges the feature into the official repository and closes the pull request.

(We are using a “Forking Workflow” so be sure to follow that description in the “How it works” section when reading the tutorial.) For another perspective on forking and pull requests, see “GitHub - Contributing to a Project” in Pro Git (Chacon and Straub, 2014), which provides a nice overview of these concepts albeit focused on using GitHub instead of Bitbucket. You can also review the configuration management notes for more information about using Git, particularly with Bitbucket.

Moving forward, the previously-described process is the one that should be used for all pull requests, including each sprint’s specification and implementation changes. Because these concepts are foundational for large-scale software projects, they’re critical to understand and be able to execute on your own. Please schedule extra instruction (EI) if you’re having trouble or would like to walk through the process with me.

Estimation

In the individual sprint retrospectives, most teams extolled the virtues of starting earlier in the sprint. Speaking frankly, I think that this lesson is best learned through experience: I certainly have a tendency to underestimate the amount of time required for tasks, and it’s difficult to prioritize tasks that aren’t due for a while when there are other pressing deadlines.

In retrospect, though, I probably should have provided more guidance to you, particularly at this stage in the semester. First, good estimations challenging even for experienced software engineers (otherwise we wouldn’t spend a lesson on this topic). Second, lacking prior experience with reviews and approvals for pull requests essentially leaves you guessing as to the time required for these activities.

Consequently, I’ve modified the schedule to include recommended dates to create pull requests for each sprint’s specification and implementation. These dates are recommendations: nothing will happen if you ignore them or submit something several days later or even wait until the end of the sprint. If you do observe them, though, you will receive feedback and have an opportunity to address any issues prior to the grading of the sprint deliverables. I hope that you find them helpful as you plan for the upcoming sprints and allow sufficient time to incorporate feedback.

Sprint Deliverables

The sprint deliverables should include the URLs of pull requests. The general form of a pull request is as follows:

https://bitbucket.org/account/repository/number/

where account is the name of the Bitbucket user who should merge the pull request (always “joel-coffman” in this case), repository is obviously the name of the repository, and number is an integer that identifies the specific pull request. I use these pull request URLs for bookkeeping: presumbably I’ve already reviewed them and provided feedback, but listing them ensures that the sprint deliverables in Blackboard provide a permanent record of your work.

Future Sprints

As the next sprint kicks off, many teams still have open pull requests related to their work in the first sprint. It is imperative that you address the comments and questions so that these pull requests are (eventually) accepted. Hence, you should allocate time in this sprint to complete the work that you’ve started. In a couple cases, there’s only a few wrap-up activities that remain to addressed. In other cases, teams are essentially starting from scratch, either because they encountered issues that prevented them from completing any significant implementation work or because I had significant concerns with the design of the implementation changes.

The temptation – one that I have often succumbed to myself – is to rush ahead, attempting to deliver additional functionality as quickly as possible. Don’t do it! First, if the foundation isn’t solid, then you aren’t going to be able to deliver anything of quality by the end of the semester. Second, your grade really depends upon what I approve in each sprint. (I will assign a grade for “work-in-progress,” but I like to provide feedback so that you can iterate on each sprint’s deliverables because that type of feedback has been the best learning tool for me over the years.) If you have a huge set of open pull requests, then it’s likely that you’ll be doing a lot of rework when I request changes to the initial pull requests. Personal anecdote: When I was leading a team that was contributing security features to OpenStack, we had to rewrite a feature three times because we failed to reach consensus on the design with the rest of the community. Don’t make this mistake yourself.

I’d normally recommend that each team talk to me about their plans for the next sprint before drafting the specification or doing additional implementation. Unfortunately, my travel precludes a face-to-face conversation, but a quick email that outlines where you are currently and what you hope to achieve this sprint is probably a good starting place. It doesn’t have to be detailed, but I want to make sure that you’re on a good path moving forward. And what if you’ve already started writing a specification for the next sprint? Well, you’re ahead of the game, but let’s still make sure that we’re on the same page for expectation management. If the plans seem too ambitious, then you’ll probably appreciate scaling back and reusing the remaining portions as part of a future sprint.