When they’re not demolishing cartons of Monster Energy Drink, our development team works long hours and does amazing things for SpareFoot. Despite the fact that we’re still a startup company, our dev team manages to handle huge and complicated responsibilities. I sat down with our lead developer Patrick Mizer, who gave me a rundown of the dev team and how they created and implemented a scaled-down version of the beautiful method known as “Agile.”
The Agile software development method breaks large tasks into smaller, incremental portions. The goal of this method is to ensure that things can be easily updated and adapted. The Agile framework is particularly effective for a small team of developers, whereas it may be inefficient in larger organizations that could be better served by a plan-driven approach.
Our dev team adapted and implemented the Agile process specifically because it was most optimal for the SpareFoot environment. “It’s all about biting off iterative chunks of development,” Patrick said. “For example, if we designed everything that SpareFoot could possibly do three years ago under the existing business model, it wouldn’t meet the needs of our customers now. We might think that people want to see search results presented on a map, only to discover that they don’t want it that way.”
To prevent this from happening, the dev team will take off a little chunk of development at a time, which ensures that they’re not wasting time to rewrite.
“By biting off little chunks and presenting them to our customers, we can iterate and reiterate.”
The methodology comes from dev meetings three years ago when SpareFoot was just getting started.
“At our dev meetings, Chuck would say, ‘I want to build these five things, how long will that take?’ And I’d reply, ‘two weeks.’ And Chuck would say, ‘that’s too long! How about one day?’ We’d go back and forth like that until I’d finally say, ‘fine I’ll do it in a day.’ Two weeks later, I would deliver the project and everyone would be happy. This ultimately tells me that reliability is more important than extreme speed and development.”
The dev team thus implemented a construct called a sprint: a time-boxed set of work that they agree to getting done.
“We might say, ‘in the next two weeks, we have 150 hours of dev resources,’” Patrick said. “We’ll take a backlog of items that the business wants created and prioritize them, then consume as much as we can off that backlog until the sprint is full. This allows us, as a company, to speak realistically about where we can be in a month or in three months.”
During the first six to 12 months of SpareFoot’s inception, the dev team was the biggest department. As the rest of the company has ballooned, however, Patrick told me that dev resources have been more scarce, which makes them more disciplined in how they prioritize.
“One unique thing is that a lot of employees here have more access to the dev team than at other companies, which forces us to get more rigorous with our prioritization.”
The process is seamlessly streamlined. If you, as a stakeholder, want something, the dev team will ask you to justify the development of your idea in what’s known as a “one-pager,” although Patrick told me it’s more like a four-pager. This is much like the abstract of a thesis; it’s composed of a background, goal section and a series of “deliverables” in story format.
“This makes it easy for technical and non technical folks to talk to each other,” Patrick said.
Once the one-pager is complete, the dev team will require a SWAG, or Scientific Wild Ass Guess. It’s not as crazy as it sounds.
“Say you come in with the idea that, as a SpareFoot employee, I want to build boats in a meeting room. We flesh out your idea and walk you through it, which is nice because some seemingly trivial things might have consequences you may not have foreseen. This process lets dev come in and put things in perspective.”
Afterwards, the dev team will whittle projects to MVP, or Minimal Viable Product, which asks the question: what is the least amount of effort required to produce something that brings value to the company?
“This goes back to the agile principle,” Patrick said. “We don’t need all the bells and whistles yet, so that we can learn as we go. People will often come into the meetings with one idea and leave with three or four. I always say it’s best if both parties walk away upset, which means that we’ve had a productive meeting where we’ve learned new things.”
During the final output of SWAG, the dev team gives the project a level of effort between one and ten, with ten being the most time-consuming.
Once the dev team has the SWAG, the stakeholder will then bring that item with them to a prioritization meeting that occurs every two weeks. The product owner will assign an impact–for example, “I think this thing is a nine in potential value.” The dev team plots these numbers on a Cartesian plane where X is effort and Y is impact, which helps them prioritize, as a company, what should be done.
“The funny thing is that we never get anything below a five impact,” Patrick said. “It’s not the most scientific process, but it’s an interesting exercise to see what the low hanging fruit is, what the no-brainer stuff is that we should knock out.”