You’re a developer eh? So what methodology do you guys use at Splice? Said no one exactly like that ever. At least not to me. But it’s a commonly discussed topic amongst developers. How do you do what you do? Do you use the waterfall method (just eww)? Scrum? Agile? Extreme? What about Rapid Application Development or Pair Programming?

For us, the answer lies somewhere between Scrum, Agile and the Wild West. As a small dev team (two developers and a graphic designer), we are tasked with moving mountains with tools meant for mole hills. We need to be light on our feet, but with enough momentum to make sure we can achieve the goals we set.

We take some of the core concepts of Scrum/Agile and use them as they make sense to us. Daily standups? Check (just not every day). Retro’s and Reviews? Check and check. Sprint planning and weekly cycles? You bet! But when it comes to the details, well that’s where some of the wild west creeps in.

Were we to follow the methodologies to the letter, I feel like we’d end up doing nothing but having 100% meetings. If we didn’t do any meetings at all, we’d have no way to know what kind of progress we are making. If we were making any at all.

Here at Splice we try to take the best bits and make them make work for us. Generally, we following the following process: Monday Morning: Catch up about the weekend. Ok, it’s not exactly a development process, but come on, we work in a small team. It’s nice to care about people when they’re not at the office.

Looks like somebody has a case of the Monday’s

Pleasantries out of the way, we get our day on. Now’s the time for production launch. Assuming there is one. We do weekly development cycles (plus a week of testing), and we try to ensure that we’re “deploy ready” at the end of each week. However not every week will include an actual production deploy. Once that’s done, then we move the previous weeks work onto our staging server.

Assuming that goes well, we can then get into Monday ‘meeting-palooza’. There’s a bunch of them scheduled, but we do our best to ensure that they are as long as they need to be; Not as long as they’re scheduled for. We’ll run through the retro and review first. Typically these run pretty quickly, but we still make sure that we address any issues that showed up in the previous weeks work & process and if we need to tweak the way we do things, that’s the time.

Once those are out of the way, we can hop straight into planning. This one varies pretty heavily from week to week. Some weeks we’re designing brand new features. Others we keep it to a short “Y’all know what you’re doing” and be off. Like I said, we keep the meetings to as long as they need to be. Sometimes that’s a little. Sometimes that’s a lot. Got to keep it flexible.

Ready or not, after lunch we run a demonstration of last week’s updates to the platform the entire office. Then after the presentation are asked to add their two cents (Feedback is good mmkay).

This lets us accomplish a few things:

  1. It helps keep everyone in the office aware of what’s going on
  2. Ensures that people can see that where their feedback has actually been implemented
  3. Gives us an opportunity to catch any show stopping issues.
  4. Let’s people know the areas they should be looking at on our staging server over the next week.

And that’s Monday. The week is definitely loaded to be heavy on the front end. But that sets us up to be more productive (or at least not interrupted by meetings) during the rest of the week.

Get Up Stand Up

As for scheduled meetings the rest of the week. Tuesday, Wednesday & Friday all have daily standups.

We cover the following four things:

  1. Yesterday I:
  2. Today I:
  3. Blockers:
  4. Everyone needs to know:

Assuming we’re all at the office, we can do it face to face. If not, then we handle it on slack. It’s not meant to be a long discussion. We just want to ensure that nobody has hit any snags along the way during the week.

We also ask that the rest of the office test out our staging server to make sure that the platform works as expected during the week. There’s no dedicated Quality Assurance team member at Splice yet, so we all share the work.

If at this point you’re thinking: “Wait, why no standup on Thursday?” Congrats for paying close attention! We have our only other scheduled dev team meeting on Thursday morning. This is where the development team meets with the Product owner to see how the week is progressing. Since we’re already talking as a group, no need to add another scheduled meeting, right?

The product owner was typically with us during the sprint planning meeting, so this is where we can close the loop on what’s been done so far, and get an idea of where we are at for this weeks progress. This is also where we also get the ball rolling for what we plan to tackle next week. Got to make sure what we’re working on lines up with our Roadmap right?

That’s a Wrap

Wrap up development on Friday, and that’s about it. We should now in a ‘Deploy Ready’ state. Of course every now and then it takes some extra time to get there, so we technically have 2 extra days to squeeze some more stuff in on the weekend. But burnout is real, and too many of those will have our well oiled machine falling apart in no time.

So that’s our methodology. It’s not 100% textbook, but it works for us. For now. That’s the nice thing about what we’ve got going on. Meeting our ever-changing needs is baked right in.