‘Being agile’ means something slightly different in every team. Everyone has different frameworks, tools, and processes, but a source of truth shared across the industry is the Manifesto for Agile Software Development. That manifesto created the bustling world of agile coaches, tools, and practices we see today.
Some teams treat “Agile” as a buzzword to implement, simply choosing a framework and rigidly sticking to it. Doing so ignores why agile shifted the culture of the software industry. As the Agile Manifesto says:
Emphasize individuals and interactions, and be open to change.
This blog will discuss various engineering techniques to help your team write better software more quickly, using the spirit of the Agile Manifesto as a guide. We’ll ensure the techniques work for the humans in your team, modify them if they don’t, and look at how other industries emphasize people.
Here are the techniques we’ll focus on:
- Pair programming
- Checklists
- Standards and templates
Working in pairs
Big-P Pair Programming has methodologies like Driver/Navigator, Ping Pong, and Strong-Style Pairing. These methodologies focus on ‘doing pair programming right’ and ensuring quality code gets written, which seem to make sense at a glance. But in reality, pair programming is often more about the people involved and their connections. We often work in pairs in Buildkite, both inside and outside the engineering teams, and have some insights to share that may benefit your teams.
It’s okay if you don’t finish work in the session
Pushing a commit shouldn’t be the only sign of a useful session. Our engineers put it like this:
“So long as things are figured out, achieved, or problems are replaced with new ones, that’s a successful working session.”
Even in sessions focused on completing code, you’ll always have tasks to finish like code cleanup, syntax fixes, and writing comments. Many of these tasks may require extra focus, or are simply things engineers prefer to do alone.
You can also have pairing sessions with other aims. For example, you can focus on figuring out a mystery, exploring a bug, or knowledge transfer (both about the task at hand and the tools related to the work). In these knowledge transfer sessions, we tend to have less experienced team members driving the session, supported by more experienced team members navigating and answering questions. To ensure everyone’s on the same page, you can start pairing sessions with a quick chat to figure out what each person would like to achieve or how they’d like to work together during that session.
Use the rhythm that works for both of you
In many Pair Programming explainers, the focus is on which roles each participant plays. For example, Driver, Navigator, and Observers. But rather than thinking about these roles and who does what, a pairing session can start as a simple conversation that falls into a natural rhythm.
For a pairing session focused on sharing knowledge, a question like “How do you prefer to learn?” is a great starting point. We find these less-prescriptive starting points useful to give participants control over the session and help everyone feel comfortable, which makes for a great working environment.
In remote teams, pairing is also a fantastic way to foster connection. There will generally be a few minutes of chat at the start of sessions before you dive into the work.
Only pair when it makes sense
The easiest way to make your team dread pairing is to enforce pairing for everything. Your team could avoid pairing because:
- Pairing doesn’t make sense for the task. Some tasks require more focus to complete or aren’t helped by having multiple people look over them.
- Someone’s having a bad day or is just tired. If someone has had a week full of meetings and long calls, it could be more productive for them to work alone for a while.
You’re trying to make pairing work for your team (not the other way around), so focus on the people.
Using checklists
Checklists aren’t exciting—they’re predictable. Checklists ensure compliance and safety, and when it comes to software engineering, filling them out is often seen as a procedural hurdle or needless busywork. But there’s a good reason high-pressure and safety-critical fields like Aviation, Health, and Food Safety use a lot of checklists: Checklists work really well.
In other fields, checklists can drive daily actions and workflows. Is that necessary (or desirable) when working with software? Here’s some guidance we think is useful.
When to use checklists
It’s easy to start ignoring a checklist when it feels like another similar-looking list of instructions interrupting your day. Simply put, remove them if they don’t serve (or continue to serve) a purpose. Beyond the cockpit describes a few principles to help decide which functions are good fits for checklists.
Processes that would benefit from a checklist include business-critical functions that would cause more problems if not done correctly, which are either:
- Repetitive tasks repeated daily, which attracts complacency.
- Uncommon tasks, which would require regular refresher training.
The most obvious use case is operations tasks. The manual and triggered tasks that SRE and DevOps teams perform are often uncommon, but important to do correctly. These benefit from clarity and repeatability. Creating checklists can also be a way to find good candidates for automation.
Writing good checklists
A badly-written checklist is often worse than none at all. The Checklist Manifesto is required reading for anyone wanting to create compelling and useful checklists. But here’s a quick summary:
- Define the trigger. When should someone pick up this checklist and follow it?
- Identify the type of checklist. The Checklist Manifesto describes two types of checklist: Read-Do and Do-Confirm. In a Read-Do checklist, you complete each step as you read it. In a Do-Confirm checklist, you do the steps as you remember them, and then use the checklist to confirm none have been missed.
- Keep it speedy. Shorter checklists are more likely to be completed. Making your checklist Do-Confirm and linking to referenced dashboards or tools from the steps can speed things up.
- Short and concise. Checklists aren’t how-to guides, they’re reminders of things you should already be familiar with.
Here’s an example to show off these ideas:
Buying a domain checklist
Follow once Product has approved the domain purchase.
Read-Do: Do each step after reading it in the checklist.
1. Purchase domain through XYZ registrar.
2. Enable auto-pay in the XYZ registrar dashboard.
3. Add basic Terraform config to ops repo.
4. Confirm the domain appears in our Engineering Finance report.
5. Confirm our parking page is visible on the domain and the TLS certificate is valid.
A good checklist is short, simple, and supports the people doing the work. Importantly, the checklist trusts that the engineer following along knows what each step means—because they’ve been through training, or they interact with the referenced tools regularly.
Keep in mind, checklists work so well in Aviation because pilots have all the instruments in front of them. When a step says “Landing Gear: DOWN”, that switch is right there to see. We get the same effect by linking directly to the pages and dashboards engineers will need to use, and making sure the checklists themselves are easily-visible and accessible.
Does the checklist spark joy?
Test the checklist! Try running through it yourself, maybe giving yourself a time limit or assuming you’re less familiar with the linked tools. Checklists are only good when they’re tried and proven, so making sure that they make sense and can be followed is essential.
Checklists also decay over time. It’s unfortunate, but it’s true! As tools, dashboards, and interfaces change, the specific steps will need updates. Sometimes, the checklist may even stop being useful altogether. Don’t feel afraid to delete them. Removing old and faulty checklists will increase your team's trust in the ones you keep.
In short: Keep your checklists simple, needed, well-tested, and up-to-date.
Standardizing your interactions
It’s easy to choose an Agile framework like Scrum or SAFe, then implement it as-is on your team. Simply make everyone create and maintain cards on a Kanban board, sit in daily stand-ups, and participate in sprint planning meetings. Enforcing this is simple because you don’t have to do any work to right-size or tweak your workflow, and in return you get to say that your team is agile.
But as the agile manifesto says, individuals are more important than processes. Methodologies like Scrum, SAFe, and LeSS can work well, but you should give your team members autonomy over their workflows.
Let’s talk about standardizing in a software development organization while emphasizing individuals, interactions, and flexibility.
What to standardize?
Keep the focus on where humans interact. Here are a few examples:
- Branch names. If one person names branches like
fix/issue-337and someone else likebilling-cart-bug-fix, that’s two separate ways of organizing and finding information about the contents of branches. - Code review flows. Is feedback given right after PR creation or once it’s asked for? Is feedback solicited using comments or by assigning others as reviewers? Getting engineers on the same page about these dramatically affects productivity.
- Incoming tasks. Or, how do bug reports and feature requests flow to your team? If your engineers have a mix of private messages, incoming Kanban cards, and repository issues, that will interrupt their focus time and stop them from getting work done. Settling on a shared, consistent process will help both the people who are reporting issues and requesting features as well.
Encouraging consistency organically
How do you encourage consistency without sacrificing your team’s autonomy? They need to know that it’s okay to question and tweak things. From a manager’s perspective, questioning processes in a blameless way is also helpful. Say that half your team isn’t keeping their Kanban cards updated. Start with a question like “Is Kanban right for our team?” or “What’s wrong with the process?” rather than assuming your team is unproductive.
Fostering respect, understanding, and open communication in your team shows that you trust them. Your reward is a group working together to find the best workflows and processes for their needs.
Starting from templates
Using templates in your work seems pretty easy to justify, and you’re likely using them across your set of tools. Still, here’s a refresher of the main benefits templates bring:
- Templates reduce cognitive load. With a pre-built template to use as a base, there are fewer decisions to make, which means more time thinking about the problem space.
- Templates encourage good practices. Put the time into configuring your templates, and those benefits will carry over to any work made using those templates. Look at your templates through the lenses of testing, security, and good engineering practices to see where to improve them.
- Templates mean less re-inventing the wheel. Let people jump straight to the impactful work rather than worrying whether they should choose npm or yarn to manage packages.
But centering humans means appreciating that templates need to be customized and changed. Small tweaks, or even rewrites and overhauls, should be a part of using the templates. We’ve all seen PR templates with tens of items that engineers don’t use. That shouldn’t be a time to punish people or beg them to fill out the form. It should be a learning experience. For example, why aren’t the engineers finding the template useful, and what changes would make it more useful? This could mean changing the template itself, or better explaining what it’s in place to solve.
As a concrete example, Backstage lets you use templates to define your software services, letting you create and modify templates yourself. Buildkite also has a set of CI/CD pipeline templates, with a public GitHub repository powering the collection so engineers can request new templates or send changes themselves. Within Buildkite Pipelines, you can use organization pipeline templates to create templates that are only visible to your organization.
Templates are incredibly powerful. If your team has the flexibility and trust to modify those templates and suggest changes, they’ll also be a beloved item in your team’s toolbox.
Conclusion
Being agile means centering your team, not just implementing one of the documented and perfected Agile frameworks. If you want to follow the original spirit of agile, evaluate these frameworks as potential ways to work and then adjust them to suit your needs. Every team is different, so you need to be flexible with workflows.
As people, we love patterns and order. Following a standard framework makes it easy to see who in the team is ‘doing Agile properly’ and who to reprimand for not doing so. But there are always individuals and groups whose work doesn’t fit that system, and cases where the process as written ignores real-world complexities.
The most beneficial parts of agile are being flexible, listening to the people around you, and empathizing with them. So instead of simply adding daily stand-ups to the team’s calendar and punishing anyone who doesn’t show up, discover the best ways to work with your particular team.
Buildkite Pipelines is a CI/CD tool designed for developer happiness. Easily follow and decipher logs, get observability into key build metrics, and tune for enterprise-grade speed, scale, and security. Every new signup gets a free 30-day trial to test out the key features. See Buildkite Pipelines to learn more.
