Our clients trust hundreds of millions of dollars in bookings to our technology and Agile has helped us ship higher quality code while simultaneously decreasing the number of issues in old code. While we certainly have client needs that require rapid development, we lean toward quality over speed. Our first scrum master, Joe Anderson, continues to travel throughout all of our five offices to coach, mentor, educate, and help new scrum masters and engineers alike to understand and embrace Agile within the company.
1 Open Positions
Transforming endpoint security with big data analytics
Waltham, MA; Boston, MA; Boulder, CO; and Hillsboro, OR
However, a number of our systems teams that tend to be more interrupt driven use Kanban instead. For new hires, the first month is chock full of onboarding and training. We have a two-day company-wide New Employee Orientation followed by a day with an R&D-specific orientation. Informally, there is a number of product training and in-depth walkthroughs of each product. You’ll also spend time getting acquainted with your scrum team and shadowing your team.
In case you were wondering, yes we pair program! We share the role of scrum master across the scrum teams so that each member is able to expand their skill set.
49 Open Positions
Agile Product Development Consultancy
San Francisco, Santa Monica, Chattanooga, New York
We advocate frequent release of working software. Sometimes the hardest thing to put into practice for larger companies is pushing code continuously. We use continuous integration, do test driven development, and try to deliver something that has business value to actual customers as often as possible. We have weekly iteration planning meetings, where developers, PMs, designers, and the project owner (usually from the client’s side) come together to plan the work for the week. It’s an open, collaborative discussion to identify what the highest value work is and estimate each unit of work. We’re pragmatic about pair programming and leave it up to individuals to decide. Most of the people here have had 8+ years of experience in the industry so we trust each other to reach out for a pair when needed. Some people pair all the time, some less than that, but everyone pairs some of the time. At the end of the week, we do a demo as well as a retrospective (with everyone from our team and from the client) to go over what went well and what didn’t go well this last week.
XP means we practice pairing and test-driven development while incorporating daily project standups and regular retrospectives to gauge project process. We find that XP is most effective given the nature of our client work, and we value close partnerships with our clients as well.
We work in sprints and a sprint of work for our developers typically lasts between 1 and 2 weeks. With our larger projects, we have a daily call with the customer which acts as an opportunity to raise any concerns or issues. With smaller projects we prefer a call or meeting with the customer at the start of the sprint and only arrange other calls as required.
We understand that software development projects are often difficult to specify in their entirety at the outset. Our agile software development processes accommodate the unknown, providing flexibility without sacrificing speed and quality of delivery. We work with customers from the outset to define the high level vision for their development project, and what they hope to achieve. We then perform multiple sprints of development – making changes to requirements following each sprint as required.
Our customers love the transparency and control this provides them.
Our product team iterates on changes and incorporates learnings as features grow. We are very deliberate about staying focused on the upcoming weeks in our roadmap. We focus on what’s ahead, one week at a time, and we realign our product goals every quarter so that we don’t find ourselves over-committing to a solution or idea without validating every step of the way.
We have Agile coaches who facilitate bi-weekly retrospectives and planning, and teams have a daily stand-up with the product owner. Every project starts with a minimum of two developers and ~90% of work is done with pair programming. We sit down together as a team regularly for code reviews. People show each other code that was complicated to write and discuss any code that the authors are unsure of or have questions about. The team provides feedback, which the authors can later incorporate in improving their solution.
1 Open Positions
Each pod has a sprint that is typically two weeks in length, and we do estimation/retros and story grooming for each sprint. Our team leads and product managers typically collaborate closely to run each of those meetings. Pods are also free to experiment with changes to the structure -- they often test out a change for a few sprints then evaluate if it’s worth keeping or not.
Data teams (analysts, data scientists, data engineers) typically work in a kanban system, as their projects tend to span longer timeframes.
Every engineering team has their sprint planning every 2 weeks. During these planning sessions, the product, engineering, and analytics teams look at the backlog and determine prioritization and focus areas depending on current needs.
Every day, we have a scrum meeting for 10-20 minutes where we touch base on where we’re at within the sprint. We keep these feedback loops short so no one is blocked, and we divvy our work into small, 2-pizza scrum teams. We follow our sprints with a retro every 2 or 4 sprints to recap our work. While there is no official scrum master, there is someone who will assume the role of the scrum master for each sprint.
We also work hard to get new hires up to speed quickly with our workflow and most end up contributing to the code base within 2-3 weeks. Within 45 days, they can usually start looking at recent tickets. For instance, here’s how it might look when we onboard engineers:
One extra training we offer during onboarding is around the credit landscape. We don’t expect our engineers to come in with credit or financial literacy, and we can teach the terminology and key points they need to know to serve our members well. If they have the skills needed to do the job, and the passion to improve lives through improved credit, we can help bridge any knowledge gaps about the credit space!
We conduct 2-week sprints across multiple (reasonably sized ~ 4-6 FTEs) teams and swimlanes. We really stress the importance of both planning and retrospectives to ensure we are constantly testing, iterating, and improving our process. We host demos at the end of sprints for the entire company to showcase and highlight what was built.
Labor Automation Cloud Platform
New York, Toronto, and Lexington (just outside of Boston)
The following are generalizations, but help paint the picture:
Sprints are keyed every 2 weeks with releases pushed out every 3 sprints. This lets us deploy significant customer-facing features about eight times a year. This is remarkably fast for an organization of our size whose primary tech is built in a monolithic codebase. (It’s worth mentioning that we are in-process of disassembling that monolith into a microservices architecture as fast as we can so we can iterate and build even faster.)
Feature Teams work on scrum, TechOps on kanban, and Data somewhere between the two. JIRA is our system of record and allows these differing agile universes to play nicely together.
Our product roadmap and vision is usually fleshed out way in advance of the engineering sprint cadence, allowing us to have a very precise idea of what needs to get accomplished when, even if all the finer details haven’t been worked out yet. Additionally, sprint planning accounts for work planning, and we’ll occasionally spike work in a sprint to ensure we understand the costing of future work. We try to minimize planning misses and unknown technical debt.
In the past 18 months, we’ve added 50 people to the product and engineering organization. We work hard to get new hires to deploy code as quickly as possible, usually within their first sprint and many their first day.
This also depends a bit on the customer. In some projects, the customer is part of the scrum team, in some projects we use agile processes internally, but do not expose them to the client. We have never followed scrum or kanban practices by the book, but mostly adapted those ideas to match our needs (and company size).
Want to List Your Company?
Submit a team profile!
Select 8 Values
Contact me (Lynne 👋)
Qualify Your Values
Reach Thousands of Devs
Find Value-Aligned Candidates
Have Meaningful Initial Conversations
Don't Fill Roles, Hire Teammates
You can post as many job openings as you want.