Sprint Retrospectives: Focus on Streamlining

In order to be first to market with a novel idea, or perhaps to make a significant improvement to an existing one we find ourselves driven by the question "How can we do it faster or cheaper" thereby attracting new consumers of your goods, services or information.

In an agile framework implemented in software development there's a ceremony (or a meeting by any other name) that's designed to achieve this reduction in time to market by identifying and modifying behaviours in the software development process itself. The Sprint Retrospective.

The structure of this particular meeting can take many flavours as we can see from the array of exercises available on sites like www.tastycupcakes.org and www.infoq.com. However, the underlying goal of all of these is roughly the same. To identify:

• What are we currently doing that we should stop (because it causes inefficiencies or is obsolete)
• What are we currently doing that we should modify
• What are we not doing that we should start (which may streamline an existing part of our process)

As a Scrum Master in the role of a facilitator of this particular ceremony, its necessary not only to provide its structure, but also to bring to the ceremony a set of documents, or behaviours, or processes used within the delivery process that the team can evaluate in context and can choose to modify in the very next sprint. Note that by bringing this list, we are not suggesting that any one of these items should be subject to change, just that it is an option for change.

In neglecting this important set of information at the outset of the ceremony, a development team might grasp at minor issues in order to 'check the boxes', and finish the meeting ASAP. Thereby reducing the ability of the team to identify and implement change which permits them to 'do it faster or cheaper'.

Keeping in mind that the retrospective is not designed to improve the 'what' of software delivery but rather the 'how', what are the categories in a project in which the items we can change might fall? A couple that come to mind are:

• Development Environment (software and hardware)
• Development Best Practice
• Delivery Process

Of course, some of the things which fall into these categories may or may not already have documentation which can be used by the team to guide their decisions on areas of change. Let's have a look at a sample Android Chat application project that's halfway through development.

What we know...

Development Environment

• OS: Ubuntu
• IDE: IntelliJ
• Version Control: Github (Using A successful Git Branching Model)
• Nightly builds with tests which are fixed the next day if broken
• Development Server with stubs
• Integration server with obfuscated user data
• Pre-Live server

Development Best Practice

• We require well structured inputs: Stories, Acceptance Criteria, User Journey (or flowchart describing the feature logic)
• We use Gherkin/Cucumber for functional testing
• Our naming conventions for classes, methods and variables are...
• We must have 90% code coverage with unit tests using Sonar.
• Our recommended design patterns are...
• Our permitted license types for imported libraries are...

Delivery Process

• We're using Scrum
• Our features are grouped into irregular releases (only release once a related set of features are complete)
• Our release types are: Major, Hotfix
• Our version number format is: xx.xx
• We deploy to our Google Store Beta (QA) group for 1 week, and if it passes...
• Deploy to live

While this is most definitely a non-exhaustive list, creating a structured list of existing documents, behaviours and processes provides a series of talking points for the team and can be added to or have items removed from it as the team finishes additional sprints. The benefit being that you then have a well curated list of team best practices which can be used in later projects, as well as having a focal point of discussion during your sprint retrospectives.