This past week, we invited Scott Carleton, a veteran tech leader and entrepreneur in NYC to come teach us all about agile.
Before launching into his presentation, Scott emphasized that the two key takeaways for this lunch & learn for us as a recruitment agency would be:
- Understanding our client companies and their priorities / processes they have in place for product development and engineering; and
- Understanding the candidates we represent and what they’re looking for in terms of engineering culture on a tech team they’re considering joining
On the principles of agile software development, Scott stressed that the most important aspects of the Agile Manifesto are that an agile team must be able to:
- Accept and adapt to changing requirements; and
- Be customer-focused.
Along with that, comes the idea of velocity, which in essence means that as long as the team is heading in the right direction and comprises the right team members, it’s enough to try to achieve a project completion goal ASAP without having to nail down exactly when completion will be. The focus should be on speeding up the group / process as much as possible.
In general, smaller teams don’t need that much process, according to Scott. As long as they maintain focus on the customer and keep the faith in the velocity of just moving forward on the project, the project usually stays on track without too many unmanageable changes, under good leadership.
Where it breaks down, however, is when a larger development team has to deal with higher-ups or other departments that aren’t directly involved in product development (e.g. marketing, business development, executive teams), or offshore engineers who aren’t as involved in the day-to-day development process. It then becomes harder to maintain velocity and “just move forward” when there are other teams wanting to know “when will this be done?” and waiting on completed features / components from the team in order to carry on doing their jobs or report back to customers.
The agile process is intended to address some of these issues, through a (usually) 4-step process that makes up a Sprint (typically a 1-2 week long cycle):
- Sprint planning – sets the pace of development, time estimation of delivery, and scope of the project
- It is important to acknowledge in this stage that completion of the scope be not defined as “do-or-die” and to create an atmosphere of psychological safety and empathy so that developers will feel comfortable bringing up all the complexities of the issues that may come up during the sprint.
- Stand-ups – typically done daily, this is when the product team gets together to discuss the day’s goals and the prior day’s achievements within the context of achieving the sprint goal
- Demo – showing what was achieved during a sprint at the end creates a sense of pride and accomplishment as well as opening up the floor for valuable feedback
- Retrospective – a recap of how the sprint went
- Scott emphasized that this is the most important part of the project. It’s an opportunity to gauge everyone’s feelings and bring to light the aspects that were good, fun, and easy as well as anything that was difficult or unenjoyable. This allows the process to fix itself and evolve over time.
The ultimate purpose of the agile process is to to deliver value incrementally and handle changing requirements.
A consistent concern of a Head of Engineering (an area in which Scott has a lot of experience) is to minimize technical debt. This could involve constantly pushing back against other departments, on a daily basis, in order to make sprint goals achievable and realistic. It also involves having the foresight during a project’s Design Sprint planning process to try to consider all upcoming complexities and accounting for them from the outset. During that process, there are five stages:
- Understanding – involves bringing in as much information as possible, spending a full day with experts, customers, and anyone with insight to discuss solutions;
- Diverging – spending a full day (ideally in the same conference room) to discuss potential complexities with representatives from the three main departments involved: engineering, product, and leadership;
- Ideally here, the three departments are equally involved and represented, like a three-legged stool
- Converging – choosing the right path;
- Prototyping – building along the right path; and
- Testing – ultimately testing the prototype.
Depending on team size, the necessity of accounting for all of these steps operate on a sliding scale. A more experienced team will be better at accounting for these but a team shouldn’t feel required to account for all of them because the process helps uncover complexities over time.
With all that in mind, we asked Scott what kinds of questions we can ask client companies to better understand their process (in the context of presenting the info to candidates) and gauge their level of technical debt. He gave us several ideas for what to ask:
- What is your product development process like? Take us through how you build things.
- (If there is an articulable process, that’s great! Engineers like the assurance that they’re not likely to be yanked around on different projects, leaving prior work unfinished / unresolved, which then directly leads to technical debt. This all comes back around to protecting clarity of scope and the engineering team’s time.)
- Do you have a definition of “done” for a project? And, as you approach completion, is there often a “crunch” time where engineers have to stay late?
- (According to Scott, it hurts the employee-employer relationship when engineers often have to work overtime to achieve deadlines that could have been avoided by careful sprint planning. This also creates a lot of catch-up debt.)
- Have you ever done a rewrite?
- (Having to do a rewrite of a codebase is a very binary idea. It means that the team is out of options and it’s time to stop delivering value on a sprint basis, put a hold on everything, and throw out the code / rework it. It creates a huge amount of technical debt and reduces the amount of faith engineers have in the product and their ability to contribute meaningfully.)
By and large, Scott certainly gave us a lot to think about! We were very fortunate to have him come in and teach us so much.
Throughout his career, Scott has worn many hats. A former nuclear engineer, his path started out in mechanical engineering as a CMU graduate. He transitioned into software engineering as the Engineering Lead of Teachers Pay Teachers early on in the company’s history, working to build out their first NYC engineering team. He then went on to found a successful tech startup Artsicle, an art rental and collection platform. Most recently, he was the VP of Technology of Andela, an international education and training program with the aim of training world-class software developers in Africa, where he still currently serves as an Advisor.