Having reviewed the various retrospectives from Sprint 2, I once again thought that it would be useful to highlight some of the common issues that I observed.

Reviews and Iterative Development

Probably the best real-life software engineering lesson for me personally is the amount of scrutiny applied to proposed changes to production software. There’s excellent rationale for doing so: In many cases, the original author(s) of the code will be those who must maintain it, and consequently, the code must be not only functional but also understandable and extensible.

That perspective is very different from traditional assignments where students submit whatever they’ve completed when the due date arrives (and the maintainability of the code takes a backseat to its functionality). For this project, though, my reviews of proposed changes (in the form of pull requests) mimics my prior experiences contributing to open source projects. Unfortunately, I’m not seeing the kind of back-and-forth that I’d expect in response to my comments. In particular, I’d expect teams to address my feedback fairly quickly, and the more that you address, the higher your grade for the sprint deliverables (i.e., specification, implementation, and retrospective). This feedback is essentially a free opportunity for teams to improve their deliverables before I ever grade them as I highlighted on the prior retrospective.

In a couple of cases, the underlying issue is that it takes me a day or so to provide feedback, but there’s also cases where I’m also not seeing pull requests until just before the sprint ends. I’ve been in that situation myself for a number of projects. Nevertheless, it means that many of the proposed changes still require substantial revisions before they could be “approved” by a project maintainer. In the real world, that means that they aren’t going to be part of the next release (because they aren’t yet ready); in this class, that means that I’m awarding only 50%-ish of the total points.

Takeaway: Use the iterative development cycle to your advantage. Address feedback on pull requests as quickly as possible. To receive full credit when grading the sprint deliverables, your proposed change should be approved and merged prior to the end of the sprint.

Pull Requests

Use lots of them! In particular, logically separate changes should appear in separate pull requests. Examples of logically separate changes include commenting existing code, implementing a new capability, and adding feature specification.

Disentangling logically-separate changes from a series of commits can be challenging. I’m always available to help if you have questions about this process.

Takeaway: Create a separate pull request for every change that you want to make.

Sprint Retrospective

A major goal of a retrospective is to enumerate issues and lessons learned. To do so effectively requires being specific. For example, it’s great to record that you started working too late in the sprint, but how late was “too late”? Maybe it was the night before or possibly the week before the end of the sprint. While that information is obvious to you now, it won’t be in a month or two. Stated differently, there should be sufficient detail to prevent another team from experiencing the same issue in the future.

Likewise, be specific when describing changes for future sprints. It’s difficult to measure improvement without having a specific objective. Using the prior example, stating that you will start working earlier in the sprint is great, but what does that mean practically? An hour earlier technically satisfies this objective but practically will make little difference. As an instructor, I want to see realistic objective setting where satisfying those objectives will improve your effectiveness as a development team. There’s also no need to sugarcoat the lessons learned: if starting the night before was a bad idea, then admit it and move forward. That admission, by itself, will not decrease your grade.

Takeaway: Be specific in the sprint retrospective.

Future Sprints

Coming into the last sprint, every team has open pull requests (which should have comments that should be addressed). It’s unlikely to have additional changes accepted when they build on existing changes. For example, a 500-line pull request that builds on an open 200-line pull request won’t be approved until after the smaller one. Consequently, receiving approval for any open pull requests should take immediate priority.

As you think about additional capabilities to implement, focus on the minimum viable product. That is, what must be added before a typical user could take advantage of your work? Better to complete a small capability than have something that is unreliable or even unusable.

Takeaway: Try to close outstanding pull requests as quickly as possible. Aim to complete a minimum viable product by the conclusion of this sprint.