4 August 2015
Releasing CRäKN, Weeks 9 & 10: How Do You Build An App Faster?
This post is part of a blog series that follows along as we work with our client, CRäKN, to build a software-as-a-service app. First post here.
It was an action-packed couple of weeks for CRäKN. The team logged some extra hours as they raced to finish features for a demo. A team changed was announced. CRäKN started the search for a full-time Ember.js developer. But underneath the surface, everything revolved around one challenge: How do you build an app faster?
In the last post, we talked about the goal to push a sellable product into market this summer, and there was a lot of discussion on the team about how to make that happen. The design and development team scrambled to finish a demo for a funeral home, and once it was in the director’s hands, more feedback started rolling in. “This is where things get tricky,” said Gaslight developer Kevin Rockwood. “A feature might be super important for one user but not for anyone else.” It’s important to figure out if it’s a more universal need (or not) and prioritize accordingly.
Speaking of Kevin, this week Gaslight made the decision to bring him and his Ember.js knowledge on the project full-time and rotate James Smith to another project in a couple of weeks. It’s pretty standard practice at Gaslight to rotate team members as the needs of a project change and Kevin had already filled in on the project while James was on vacation. In fact, CRäKN even started thinking about hiring a full-time Ember developer to help the project move faster and maintain the app long-term.
“Everyone is getting wrinkles,” said CRäKN product owner Shawna Becknell. “People’s faces are scrunched. That’s bad. No one’s face should get scrunched over software development. But we still have this date. If we can’t cut scope and we have to hit the date, can we get an Ember person? Would that increase velocity?”
Kevin felt pretty strongly that it wouldn’t and headed to the whiteboard to chart out a new developer’s impact on the project. “Velocity is slowly gaining right now,” he said, drawing a line. “If we hire another person, velocity will go down for a period. Then it will come back to even. Then, hopefully, the velocity will increase more.” It takes time to integrate a new person onto the team, and more developers don’t necessarily make a project move faster.
Shawna expressed an interest in pulling out smaller side tasks for the new person to work on while Gaslight continues to build primary features. But in the end, it all needs to be maintained, tested and reviewed. “It can be really hard to tease stuff out,” James said. “It’s all connected. Development stories are rarely completely isolated from each other. There are subtle interactions even with the most isolated features. ”
Though as CRäKN Chief Technology Officer Cliff Campbell pointed out, there’s a larger surface area to the app now, so it could be easier to find features that wouldn’t touch a ton of other things. He’s also thinking about the future when CRäKN will take over maintaining the app after the initial build. So it makes sense for the team to add a front-end developer and begin to take over more development tasks.
In the end, there’s no magic way to go faster. But the team agreed to work together to balance hitting goals with working at a sustainable pace. Check back soon to read about mentoring, interviewing developers and trimming down scope.
