The 11 Agile Processes We Use to Run an Efficient Software Team process.st /agile-processes/ 7/26/2017
Benjamin Brandall July 26, 2017
Maybe some teams can get by without strictly following documented processes every day, but when it comes to agile software development teams, it’s simply not an option to operate in the dark. Since software is complex and easy to mess up, processes mean the difference between a great product and a crappy one. Without processes, software teams will spend more time squashing bugs and dealing with support headaches than they will actually developing the product‌ The exact reason we created Process Street is to help businesses avoid that nightmarish cycle, and, of course, we use Process Street ourselves to help run the agile processes behind the scenes. We use regular agile processes like: Daily standup meeting Sprint planning Sprint turnover Sprint retrospective We also run routine QA processes like: 1/11
GitHub pull request procedure Weekly WordPress maintenance SSL certificate renewal And, finally, we have a set of training processes: Developer onboarding How to set up your development environment Pull request review failed procedure Pull request merge procedure These are all regular tasks for the team, and the reason they were created was because we found they have a high margin for error. Scroll down to find the exact processes we use. If you want to tighten up the way your software team works, hit your sprint targets, and efficiently train new development hires, then this post will show you how. We even reveal the exact processes we use and a workflow diagram detailing the journey an issue takes from start to end.
2/11
The above flowchart shows how the Process Street engineering team adds issues to JIRA, and where the issues first come to light. While bugs are often added as issues as and when they’re found (either by the developers or by users), features are planned first in ProductBoard and go through a longer approval process before they’re collected into a spike and added to JIRA. All of this happens before the issues are assigned to sprints or developers.
3/11
The diagram above represents the workflow for sprints. Sprints are bursts of work that last 2 weeks and have a fixed list of issues to tackle. The issues are added to JIRA as shown in the first chart, and then during the sprint estimation step, they are assigned points. Each sprint looks to close around 16 points worth of issues, and is kept running smoothly thanks to daily standup meetings. During the meetings, each team member reports on their progress and voices any concerns they have. At the end of the sprint, the team gets together for a sprint retrospective. The purpose of a retrospective is for the team to evaluate how well the sprint went, recognize each other’s achievements, and make suggestions for what can be improved. In this post, I’m going to show you all of the processes in detail and give you copies so you can use them in your 4/11
own teams.
Our key agile sprint processes Since sprints are only 2 weeks, they need to be well planned, tightly managed, and constantly optimized. For that, our development team uses 4 processes. In this section, I’m going to embed the exact processes we use, and explain why we use them.
Daily standup meeting checklist The daily standup meeting is a core component of agile methodology. It’s a way for the whole team to check in on the progress of a sprint, and take care of any problems. The development team meets every single business day to make sure that no member of the team is stuck on a problem for more than a few hours, and so that the team leads can get a pulse on how quickly and effectively the team is working.
Cameron, our CTO, tracks attendance as the first step of the checklist. Using Process Street’s template overview, it’s easy to see a track record of attendance and identify who needs catching up with the topics discussed. To ensure everyone can follow along with the process, we’ve set up an integration between Process Street and Slack that sends a notification to the #developers channel with a link to the checklist.
To use this integration and connect Process Street checklists to your Slack channels, you can use this shared zap to get set up in minutes: Send Slack messages for new Process Street checklists 5/11
Use this Zap powered by Zapier To prepare for the meeting, team members add their WIP issues to the “Staged/In QA” list in JIRA. Cameron filters the list by member, and goes through everyone’s issues one by one. If possible, the issue is demonstrated with a screenshare where the team is welcome to criticize and ask questions about the solution. The standup meeting checklist has gone through a few iterations since it was created. Notably, there is now a step to ensure that pull requests are all accounted for across all repos, and that no issues end up orphaned. As well as that, the process has been updated to include a step to check the burndown chart every day, to get a clear idea of the sprint’s progress.
Sprint Turnover Every two weeks, the last sprint comes to a close as the upcoming sprint is planned. This whole process is known as sprint turnover, and needs to be documented because issues can easily be overlooked or left unassigned.
“It’s super helpful to have a process for sprint turnover, because we always used to miss the JIRA search parts and issues would stay hidden and forgotten about instead of being added to the next sprint. This way, it’s consistent and we don’t miss anything.”
Essentially, the turnover process is JIRA maintenance. It ensures the team updates JIRA to reflect the work they did in the previous sprint, and uses specific JIRA search queries to find issues that might otherwise go missing.
6/11
Sprint Retrospective Sprint retrospectives are vital for continuously improving the way your team runs their agile processes. Put simply, the team discusses the following points: What went well during the sprint cycle? What went wrong during the sprint cycle? What could we do differently to improve? The same way we track bugs and features in JIRA, we also track issues that aren’t coding-related. The process pulls these answers into a separate text area so it’s easy to paste into JIRA as an issue. Here’s an example of one of our completed sprint retrospective checklists:
7/11
This information also gets summarized in Slack via a Zapier integration, so the team can review the information after the call:
Sprint Estimation 8/11
Sprints should consist of a balanced and achievable amount of work, so issues must be carefully estimated and assigned. For this, we use Planning Poker. The planning poker method (originally discussed in this paper) helps weight each team member’s estimations equally. Each issue is assigned story points based on how much effort the issue is estimated to take. Instead of speaking the point estimates out loud, players place cards with their point estimates face down, and then reveal them at the end.
This checklist is for ensuring no issues were overlooked, and then prompting the team to start Planning Poker.
Pull request QA processes The Process Street development team uses three processes to handle pull request QA. The first is how to create a pull request, and includes links to automatically push the data inside the process to GitHub. The other two (pull request failed review and pull request merge) are more for training than regular execution, and come as part of our developer onboarding processes. (More on those later.)
Pull request procedure Pull requests can be risky, so the development team put a lot of emphasis on making sure that it’s done with care. This means using a process for every single pull request. The process includes steps for thoroughly testing, and then automatically generating a PR in GitHub by pulling the title of the checklist into GitHub as the pull request name. This works by inserting the checklist name into a URL with a variable. Since the pull request procedure is run regularly, it’s where Cameron adds tasks for extra bugfixes, just to whittle down the bug backlog little by little. For example, a current goal is to passively get rid of all Scalastyle issues, so one step of the PR procedure is to resolve one issue.
Pull request review failed procedure 9/11
This is a process that has a lower margin for error than a PR, and is easier to learn. It’s used as a way to train new team members on the way we do things, not specifically to be ran every time. The main purpose of the checklist is to ensure that developers review comments on GitHub and JIRA, apply the changes, and then thoroughly re-test the issue. When it’s complete, the URL of the checklist is attached to the JIRA issue as proof of process adherence.
Pull request merge procedure Before a pull request can be approved and merged into the live branch, it needs to be proven that it will fix the issue and not break anything. That’s what we use our merge procedure for. Pull requests need to be submitted with a test, a description of the test, and, ideally, a screen-sharing session with a member of the team.
Processes we use to keep on top of regular maintenance It’s easy to overlook scheduled tasks, but if they’re not dealt with you can end up with security vulnerabilities or running your These run on schedules, and cover both the user-facing areas like WordPress and the Process Street app.
Weekly WordPress maintenance WordPress maintenance helps to patch holes in the security of our site. Plugin updates and new WordPress releases often serve to fix security exploits, so we always need to be making sure we’re updating plugins as soon as we can. We have this process set to a schedule. Every week, Process Street automatically runs a checklist and assigns it to Madison.
SSL Certificate Renewal Even though we only use this process once every three years, Cameron says it’s one of the most useful. Before he had it documented, Cameron needed to look up the steps and work out the best way to do it every time.
10/11
To make matters worse, the SSL renewal process is difficult and arcane. Now, it’s scheduled to run automatically and send a notification so Cameron can come in and get it done quickly. Process Street is useful as the home for your regular tasks, but also as a place to store procedures you use occasionally.
How we use processes to painlessly onboard new developers Onboarding equips a new developer with the tools and knowledge they need to be just as efficient as the rest of the team. Before we had a proper process, it’d take Cameron 2-3 days of back-and-forth to onboard a developer and a lot of screen-sharing. Now, he just needs to send the developer links to 3 processes, and then watch as they fill the checklist out and get set up on their own.
“It’s as much an onboarding checklist as it is a checklist that improves my quality of life.”
We use one main onboarding checklist for getting the new hire set up with Slack, Trello, JIRA, and all of the tools we use. Then, linked inside that checklist is another (much more complex) process for setting up the Process Street development environment. Here’s the main process we use: Inside that process, you’ll notice links to the pull request processes for training purposes, as well as a link to getting set up with the development environment. You can take that same checklist and modify it to fit the way your team works.
How do you run your agile processes? It’s only natural that Process Street engineers use Process Street to run their operations! We see it as a mark of quality that our super-efficient developers can rely on Process Street to give structure to intense sprints of work.
11/11