Becoming Agile
I recently finished a contract with a Health-Tech startup, where I was installed as the Tech Lead. It was a unique opportunity to learn about a different domain, and to share some of my industry knowledge. One of the largest struggles during my time as Tech Lead was installing an Agile and Scrum workflow. This blog post will outline some of the Agile big ideas I implemented.
Incremental Change Management
Agile development is all about incremental change. When implementing Agile from first principles, it’s important to start small. Instead of jumping in heads-first with a full-fledged 2-week sprint cycle, I had decided to start with implementing a basic Kanban workflow. Since there’s a non-negligible overlap between Kanban and Scrum, the team was able to get used to the tooling before introducing more changes.
After a handful of the Kanban sprints had finished, I set up a Scrum workflow for the team using Atlasssian Jira. The following sections will outline some important features from Scrum which I had implemented for the team.
Collaboration Through Tools
Successful Agile involves successful collaboration. Through Agile, business and engineering can cooperate on building successful products. The question then arises, how can business translate requirements for engineering, and how can engineering translate progress and blockers for business?
Jira
Atlassian Jira is an amazing tool for implementing Agile. Jira allows for Kanban and Agile workflows, and is excellent for different business units to communicate. The following sections will outline how to practice Agile through Jira, but many of the concepts transfer to other project management products.
Roadmaps
Roadmaps in Jira are immensely useful for planning an Agile project. With roadmaps, you can define deliverables by epics, install due dates, and view progress. Associated user stories can be grouped by epic, and Jira can visualize the planned sprints for each epic (see Fig. 1).
Fig. 1. The roadmap visualization in Jira cloud. This example project contains 3 epics with various due dates.
The Backlog
Perhaps one of the most important tools in any Agile workflow. The backlog tells engineering and business which tasks have yet to be worked on, and which priority should be given to each of those tasks (see Fig. 2 for an example backlog).
In Jira, tickets are stack-ranked by priority, meaning the tickets with the highest priority should be placed at the top of the stack. If using the Jira Sprint configuration for the backlog, tickets which are assigned to created sprints will also be visible. The epics for which the tickets are associated with are also visible.
Fig.2. An example Scrum backlog in Jira cloud.
Backlog Grooming Cadence
A backlog is not very useful if it’s not regularly maintained. A key feature of project planning in an Agile structure is backlog grooming. Note that depending on team size, backlog grooming can be a separate meeting from sprint planning (see the next section on Sprint Planning). This is a regularly scheduled meeting (every week for example), where product, project, and engineering ask the following questions:
Are the priorities for the tickets in the backlog correct? If not, what are the new priorities. Note that priorities can change often due to changes in product requirements or organizational changes (engineers leaving, onboarding new hires, etc).
Are there tickets which can be assigned to planned epics? If so, associate the tickets to the correct epics.
Are there any duplicated tickets? Sometimes tickets can be created when a relevant ticket already exists. A suggestion for dealing with duplicate tickets could be creating a new ticket state, ‘Duplicate‘, for example, for duplicated tickets to transition to.
Sprint Planning Cadence
Once the tickets in the backlog have been groomed, we’re ready to start planning sprints. This meeting should occur on the boundary of the end of the current sprint, either on the last day of the sprint, or immediately on the day after.
Ideally, the sprint planning meeting should have as many stakeholders as possible. This should include every engineer on the team, since they’re the ones who will be delivering the artifacts, and any problems in ticket or sprint scope can be caught earlier.
Care should be taken such that no one engineer is burdened with too many tasks to complete within the sprint. Using story points with planning poker can help facilitate this. With planning poker, a consensus on the level of effort needed to close a ticket is agreed upon. Typically, the level of effort is represented by Fibonacci integers (1, 2, 3, 5, 8, 13), and the team agrees to a soft maximum of points allowed for the sprint. For example, let’s say the soft maximum of points is set to 25, with 3 engineers on the team. This means each engineer could be assigned a ticket worth 8 points. Alternatively, one engineer could be assigned a ticket worth 8 points and the other two engineers could be assigned 2 tickets each, worth 3 and 5 points each. This will obviously vary depending on the individual engineering skill and experience level of each engineer.
End of Sprint Retrospective
Another very important feature of Agile, the retrospective, occurs after a sprint cycle ends. This meeting is used to provide information to help make future sprints more efficient. All stakeholders should participate in this meeting, and the following questions should be addressed:
What went well during the sprint?
What did not go well during the sprint?
What action items can be taken in the future to improve on future sprints?
The answers to these questions should be documented in a central repository (Google Docs, Confluence, etc). When looking at past retrospectives, we should see many of the action items addressed as more sprints are completed.
In Closing
This post was an attempt to highlight some of the big ideas in Agile project management. Each one of these ideas can be delved deeper into, and the exact implementation will vary depending on team size, experience, and domain constraints.
Jira itself contains a vast array of configurations, and this post did not dive into how to set up workflows and boards. I highly suggest taking a look at the Jira free plan to get started.
