What Does 10 Years Of Agile Scrum at BrightMove Look Like?

Published on 9/16/2022 by Jimmy Hurff

Categories: HR Tech

Tags: agilescrumtechnology


On Thursday August 16th, 2012, the development team at BrightMove began sprint #1 using the Agile Scrum methodology.  Just a few weeks prior, an epic that we referred to as Exchange Sync MT Engine was formally realized into the team's product backlog.  These events were significant milestones in the transition to using the scrum framework within our development organization.  They represent the beginning of a journey.  Over the next 10 years, the BrightMove development team consistently, reliably & incrementally delivered new features and value to our customers through this proven iterative delivery model.  This past week, we completed sprint #162.  The new features and enhancements from sprint #162 will be released as 2022.10.0 in the next few days.  

At BrightMove, we are a software development company.  Our goal is to build software that our customers love to use.  Today, we share this 10 year anniversary of a significant internal milestone for two reasons.  First, to celebrate our team's steadfast dedication to the BrightMove mission, vision and values.  Second, to let our customers know what we value most dearly.  Them.  Our developers, analysts, architects and support specialists work days, nights, weekends and holidays to ensure we release the best product possible.  We are not claiming to be bug-free or to have delivered 100% uptime.  However, we do claim to have a very high say/do ratio, integrity that we are willing to stand on and a relentless pursuit of customer delight.

undefined

The Predictable Lifecycle of A New Feature

The software development cycle (SDLC) at BrightMove is based on a very simple workflow.  An assembly line is a good metaphor for our SDLC.  Like an assembly line, once you place a new feature request on the BrightMove Agile Scrum conveyor belt, you can be assured it will be delivered to the proper destination.  For our development team, following this workflow allows BrightMove to reliably deliver software into production that thousands of customers depend on and use every day.  Every workday, at 9am eastern time, our development team gathers for a ritual - the daily standup.  In the 15 minutes from 9:00 to 9:15, each member of the team shares what it did since the last time it met, what it's going to do next and any blockers that are in the way.  You can set your watch to this ceremony.

undefined

Spotlight: Jake Pharr, Our Technology Development Leader

Under the leadership of Jake Pharr, VP of Technology Development, the BrightMove development team is highly trained in this software development life cycle.  Over the past 10 years, Jake's team has brought forward all of the new features to BrightMove's customers.  Jake is a talented engineer himself - he has deep expertise in React, Java and Amazon Web Services and is a world-class software developer.  Some of our customers' most favorite features were developed by Jake personally.  His personal contributions in the Applicant Experience Portals, BrightFlow and BrightSync have been critical for the successful adoption of the BrightMove platform.

undefined

An Assessment Of Scrum From Our Development Leader

What is the best thing about the Agile Scrum methodology?

"Scrum provides predictability and accountability.  It allows me to plan the next two weeks and enables focus on specific parts of the application by biting off in smaller pieces", says Jake Pharr.  "We're only committed to doing what we know we can do.  It's a really good scientific process because we have insight from our increment.  Because of this, we ship a lot of software."  Through the Agile Scrum framework, BrightMove is able to ship more features in months compared to what some companies do in a whole year. 

What should you watch out for when using Agile Scrum methodology?

"Prioritizing bigger projects and initiatives can be difficult, if you're not careful", says Pharr.  Scrum can provide focus, but it can also accentuate smaller, high visibility features.  These can potentially take away from bigger, higher priority initiatives if you're not careful.  To deal with this, Jake suggests you have quarterly objectives and roadmap targets.  Also, he suggest you watch out for scope creep within seemingly small feature requests.  "Scope creep can take away time from the important things you've planned to do."

What is the one piece of advice that you'd share with a development leader regarding the Agile Scrum methodology?

"Make sure you have a process for feedback loops, product management and polish", says Pharr.  "The team is going to deliver a production increment through the sprint, but it may require more polish after.  The code will be ready, but it may need further refinement."  Product features will have a lifecycle, and for companies that thrive on velocity, they can find themselves with a large amount of MVP code.  Sometimes, the team finishes a sprint feature and moves on to the next feature.  This can lead to many good features, but no great ones.  Don't forget to leave time to polish.

Grooming the Backlog

If we go back in time to Thursday July 26th 2012, our development team was gearing up to implement the scrum methodology.  Our initial backlog had just been created and we were grooming our epics and user stories in alignment with the scrum framework.  Leading up to that point, we found ourselves in a pattern of delivery that wasn't as predictable as we desired.  As a team, we wanted to produce higher quality software, with more predictability and fewer defects.  Our software stack is very complex and our customers' requirements are even more complex.  We believed moving to scrum would result in better overall velocity, as well as improved quality of our SDLC assembly line.  While we have made a few improvements and adjustments along the way, many of the same activities we started 10 years ago are still in place.  To this very day, every Friday, our development and support team gathers to review customer feedback requests and other support needs.  That feedback is then incorporated into our sprint development plan.  Jake personally, consistently and reliably leads this effort with the singular goal of building software that our customers love to use.

At BrightMove, we have 3 week cadence, with 2-week sprints.  The purpose of the 3rd week is to groom and refine the backlog for the next sprint iteration.  

BES-1: BrightMove's BrightSync Exchange Sync MT Engine

First, let's decode this technical jargon.  BES-1 is the Atlassian Jira ID for this major (turned critical, see below) feature, called Exchange Sync MT Engine, with the BrightMove platform.  BrightSync is our portfolio of synchronization tools that connect to third-party services like the communication platform, Microsoft Exchange.  BES-1 represents the unique ID of the feature, associated requirements, work history, testing notes and code commits our development team executed in order to create the feature.  The feature is a multi-threaded synchronization engine that enables Microsoft Exchange server integration for our customers, and syncs their email messages, calendar entries and contacts within BrightMove.  In the grand scheme of things, this is just one Jira in a backlog of many, but its place in history for BrightMove is as the first feature that went into our new, shiny Agile Scrum product backlog.  BES-1 was the first story in the Agile Scrum era for BrightMove.

Three Weeks And A Cloud Of Dust

At BrightMove, our development team operates on a three week cadence.  Our sprints are always two weeks in duration, with one week for grooming & planning in between.  The week in between sprints allows our development team to prepare for the next sprint.  At the end of each sprint, we release code into production to be used by our customers.  This has happened 162 times over the past 10 years.  Sprint #1 began on Thursday August 16th 2012 and ran for two weeks, ultimately resulting in the release 10.8.0 of the BrightMove ATS software.  As you can see from the list below, we added some key features, like WYSIWYG (what you see is what you get) to our email editor screen.  This is because everyone likes to format the fonts to their liking when sending emails to candidates.  We also made significant strides towards the creation of the Exchange Sync MT Engine.  The initial version of this Exchange Sync MT Engine was released later in 2012, and the project was marked as fully complete and closed in 2014.  Since it's delivery, Exchange Sync MT Engine has processed many millions of emails and tasks for our customers.

Sprint 162: 10 Years Later and a Kick Ass Say/Do Ratio

WARNING: Nerd humor forthcoming.

If you want to see an engineering leader puff his chest out in pride, ask him or her to show you their best burn down chart - the one he or she is most proud of.  You see, the burn down chart is a great way to tell the story of a software engineering team's maturity and integrity.  Specifically, it is a way to demonstrate a team's say/do ratio.  In case the term is new, Say/Do Ratio is exactly what its sounds like.  It is a measure of how much of what a team says it is going to do, compared to what it does.   It showcases a team's commitments compared to deliverables.  It is also a great way to become  aware of impediments and issues that could impact delivery.  In scenarios where burn down lines are not going down, it may be indicative of an impediment or an issue.  Team members can use this information to make adjustments.  Burn downs can also indicate whether there is too much capacity (or not enough capacity) to get all of the committed work done in the planned amount of time.  For Sprint #162, after 10 consecutive years of sprinting, our development team took in 25 Fibonacci points worth of committed work and delivered 25 Fibonacci points worth of value.

100% Say/Do Ratio 

At BrightMove, we take great pride in meeting our commitments.  We aim to meet our commitments to each other, to our business partners and to our customers.  It is core to our promise: we will innovate and we will support you.

A Few More Vanity Metrics For The Nerds In The Audience

Here are a few more metrics that we're proud of that we'd like to share on this 10 year anniversary.  

  • Number of git repositories: 55
  • Number of Projects in Atlassian Jira: 18
  • Number of Epics in Atlassian Jira for ATS: 41
  • Number of Issues in Atlassian Jira for ATS: 1000s+
  • Number of Commits into Source Code Control: 14,534
  • Number of Pull Requests: 461
  • Number of Emails Sent Via Exchange Sync MT Engine: 2,007,109

Thank you to our development team for all of this great work through the years!  Well done.

About BrightMove

At BrightMove, we are a software company.  Our goal is to build software that our customers love to use.  Today, we share this significant internal milestone for two reasons.  First, to celebrate our team's effort and dedication to our mission, vision and values.  Secondly, to tell our current and prospective customers what we value most dearly.  Them.  Our developers, analysts, architects and support team work days, nights, weekends and holidays to deliver on our promise - we will innovate and we will support you.

BrightMove is the perfect ATS for staffing agencies of all types and sizes. Whether you are an executive and retained search firm, permanent placement agency, or responsible for contingent staffing, BrightMove will meet your needs and exceed your expectations.  BrightMove was created for recruiters, by recruiters. BrightMove for Staffing is software for hiring employees and contractors. It is cost-effective employment agency software that is streamlined for your business. It can be customized to fit your recruitment process, so you can find the right candidate the first time. No workarounds required.

For more information on BrightMove for Staffing, please schedule a demo with one of our customer success specialists.

Try It Now


Make a BrightMove: Sign up for a free applicant tracking system trial

Start Now