729 Solutions originally began as a digital agency in the dot-com years, but under President and CEO/CTO Rob Fife, it’s morphed into a boutique agile shop that provides front-end UX/design and backend help to startups and Fortune 500 companies.
We spoke with Fife and Director of Business Development, Graham Silbermann, about how they experiment with agile, soggy vegetables, and life without (engineering) rock stars.
Graham Silbermann: I think it would be appropriate to say we were originally a “dot net” shop. However, we kind of grew around the need of multistack engineering problems. That's really where we've seen the most demand: trying to figure out how we can we solve these problems and realizing that none can be solved with any one framework or language.
That's how we evolved into only hiring multistack engineers. Everyone has at least one or two languages and frameworks because all of our customers will need that. In more recent times, we've been focused on our partnerships, because we’re there to support their professional services side. 729 increasingly supports professional services and sales activities in other fast-growing technology companies.
Rob Fife: We have a bit of a different thought process around what testing consists of, so TDD didn't really make sense for us. We were also doing something that we tell everybody else not to do, which is that we were cherry-picking agile—a little bit of this, a little bit of that, sprinkle some stuff on top. The way to frame it is you have to understand the dynamics of a closed ecosystem. It's the same thing as keeping a fish tank.
We tell the clients and startups when they ask how to do this stuff, “You've got to be prepared to do post-apocalyptic agile. If you can't do this with Post-it notes or index cards and a roll of tape, then you can't do it. There is no tool that you should be that dependent on.” That being said, you should choose a tool. These tools are slightly opinionated in the same way that Ruby says it's opinionated software.
Rob Fife:Tracker has a leaning towards that [agile] style of development, which we happen to think is the right way to do software development.
We went from a big office in Burlingame to having everybody spread all over the place, so we couldn't use spreadsheets or cards or Post-it notes anymore; we couldn't scribble on the whiteboard together. A lot of the tools that are around now didn't exist.
We use our version of XP—what we call velocity-based agile—with Tracker as the centerpiece of how we sell people during the pitch process. When we do a scoping call, we do it a bit more over the course of time, organically. But out of that scoping approach, we have the engineers write stories at the same level they would if they were going to build whatever the thing is.
Now when we make our pitch, we’re confident of the outcome. For example, a couple of years ago we had an 18-month project where we were a subcontractor and we missed it by two weeks over 18 months. That is a sell for you guys to use Tracker not just to manage an existing project, but to scope. And to present that scope to the customer in the form of a Pivotal Tracker board.
Our approach to this is still very much: next developer up takes the next story in cue. You know 10x developers create 10x the technical debt. We're a “no rock stars” kind of company. It doesn't mean that people aren't good, just that we don't have any use for those people. I don't need people who are going to stay up all night; I need people who are going to put in their eight hours and go home and be happy on Monday morning.
The bigger projects we do—as well as being able to put time, cost, and scope back into the pie chart—and showing them the evidence for how their choices impact the timing and the cost goes a long way in sales.
Rob Fife: We've also become pretty good at explaining, “Look, it comes out in the wash.” All the time we spend wrestling around this, we're here to win. What does victory look like? Do you want to fight over minutiae or do you just want to get this done? The faster we get it done—it's actually counterintuitive, but—mathematically you save money because those PM costs, those design costs, all of that overhead is static. It's consistent you're going to use it for two weeks, twelve weeks, or 100 weeks, but four developers can go faster than two until you hit a certain cap.
But in that time, you can get through so much more work. You can make a decision about what's the right thing, the must haves, the nice-to-haves, what's the discovered scope. Does your concept even work?
Rob Fife: We tell them, not only do they have access but technically they own the board. Even if they don't hire us, that's the way—the sales pitch from us or the approach we are taking—the best way for people to feel comfortable working with us is to work with us.
When people do work with us and they see what it's like, they don't want to stop working with us. What they find is, “Hey, we've been going back and forth over the course of six weeks and we have this backlog and we know what the future looks like. Might cost more than we thought, but we also got to understand how we can mitigate some of that cost by pushing things out further."
You know, the cream rises to the top, and for the rest, they get to choose: how badly do I want those ten things I no longer have the budget for?
Rob Fife: Customers are rarely willing to do what we want them to do and engaging the customers’ technical proficiencies is one of the harder things. So if we make it their responsibility to own the project with PIvotal Tracker for things like the missions and signoffs, then it behooves us to make sure that they use the tool, and they're engaged in it. That can be a challenge for any agency. If an agency has a very wide range of customers, those customers have a very wide range of experience. Will they all use the same tool?
That is certainly a problem we struggle with and I'm sure every agency like us would struggle with the same problem. We could have a problem as annoying as someone who is very technical but they've only used a certain tool before. That's just what they know and they have a hard time relearning, you know old dog and all the rest of it. Or we might have someone who's never done a technical problem in their life who doesn't even understand what a story is. “What does that mean? What's a story?” Even that language is a battle.
We're not here to write stories; we're here to solve business problems. So we always start with a list of measurable goals and then use whatever mechanism we can to get stories into Tracker. The more technical clients quickly learn to frame granular features with "User performs action and sees result- type verbiage, whereas others can frame it for us in broad brush strokes: "As a user, I'd like to do a thing." On some projects, we end up writing all the stories, and on others, the client is writing them all by the end of the engagement. All that matters is that we get them into the backlog."
Rob Fife: I would say the big one is to pick a philosophy and embrace it wholeheartedly, which is the extension of understanding the dynamics of the closed ecosystem. The fish tank thing.
If you do scrum, be really effing good at scrum. If you want to use old-school construction methodologies like they used to build the pyramids with Gantt charts and all that stuff, go right ahead. Just stick to all the rules until you have an expertise, a mastery of both the subject and the context, and then you can tweak it. Who takes the soggy vegetables in the school lunch line in that little corner of the cafeteria tray? Nobody, right? You've got to eat those for a reason and as soon as you say, "Oh I'm going to pick this and pick that and pick something else and maybe I'll get something across the street." It's not longer a cohesive system. Somebody way smarter than all of us already thought through the basics of all of this and they understand, again, how time, cost and scope are locked together. So are all the aspects of these project management tools.
Graham Silbermann: My advice on the tools side is for agencies to invest on customers learning and using the tool right from the start. The projects where we've had the best results have been the ones where we've really encouraged the customer to use Tracker, get involved with writing stories, use it for permissions, that sort of thing.
Rob Fife: I think that's where it's benefited us. You can probably craft us into a testimonial of some sort because there are a lot of project management tools out there for software but we are of the opinion that some form of velocity-based agile is the right way to do this. That scrum is sort of a waterfall in agile's clothing and everyone is fired up on this scrum thing but velocity-based stuff is the way to do it and Tracker is by far the best to manage that process with and get the insights you need to be successful.
Tracker gives us a really nice, visible place where the customer can clearly see what we’re doing and where we’re headed.
They want to see deliverables, they want to see that we're executing onto the specific group of tasks and Tracker is a great way for us to share the project so that the customer gets their project done in line with how the partner wants it done.
