How We Work: A Calmer, More Thoughtful Development Practice

We have been ‘experimenting’ with the way we organize development at Castos for the past year or so.  By ‘experimenting’ I very much mean learning as we go and just figuring it out…as is most things in a small business.

It has evolved a lot from email and a Google Doc to a team of 4 developers with several different areas of focus of our tech. With these changes a lot of things about how we work needed to change. And some of it has, but much of it hasn’t.

First let me tell you that this article is not a “look at how well we do things in our business” type of Entreporn where everything is Unicorns and Rainbows, but rather “we’ve been doing this really wrong for a while now and this is how we’re going to fix it”.

I have to admit something:

I am without a doubt an unorganized and spontaneous person. Definitely not Type A.

But I LOVE working with people who are organized, methodical, and very much Type A. So I have to put on that hat. Especially when it comes to managing our biggest group of Human Resources, our development team.

At this point Castos is a really stable platform and our Seriously Simple Podcasting plug-in continues to perform great with 150+ 5-star reviews in WordPress.org. As such we have the opportunity, and almost the obligation, to become less reactive and more proactive with how we work…especially when it comes to development.

To give a bit of perspective our current Project Management workflow looks a little something like this:

• We have a slack #dev channel and a Clubhouse board where we have a list of about 30 things we want to do.
• I start each week (and many days) by pinging our developers in Slack individually to let them know which of the 30 cards we need to work on. What’s “critical” today, and what “needs to get shipped” because of one reason or another.
• All of this changes, sometimes because of new bug/feature requests we get, but also maybe because I just haven’t properly thought through what’s really important.

How many of you are nodding your heads right now?

It pains me to write this, but along with all the great stuff we get to write about as entrepreneurs we ought to write about the things that kind of suck and need fixing.

So with the first quarter wrapping up soon we’re going to start a new way to work on April 1. And no this isn’t an April fools joke.

It’s true that this post is as much a manifesto about how I would ideally Like our team to work, but also something that I’m setting in stone, and hoping that everyone reading can help keep me accountable to.  So, here’s what our new development workflow will look like:

Tools We Use

Instead of being Slack-centric we’ll be Clubhouse-centric.

Clubhouse is a Project Management tool that’s built for development teams. We’ve been very loosely using it for the past few months and it’s great. But now instead of a secondary place just to store some updates and new features/bugs that we’re going to work on it will be the first place to go for information and updates about anything and everything that we do.

We have a few columns in our main Clubhouse view: Unscheduled, Ready for Development, In Development, Ready for Review, Ready for Deploy, Completed. These line up perfectly with how we already work, and is a great way for both me as the project lead and our developers to easily see what’s what when it comes to the project as a whole, and our individual assignments.

These Stories all roll up into Epics (groupings of smaller tasks that would make up a single big Feature) and Epics should all lie inside a Milestone. A Milestone may be something like “Relaunch Marketing Site” where there are a bunch of pieces to put together.

Above the Milestone level is Projects, which I think of as business units.  For us since we have both the Castos web app and the Seriously Simple Podcasting plugin each of those is their own Project, and you can view Epics/Stories from that level too.

We will of course still use Slack for smaller clarifications, when we’re troubleshooting something more real time.  But the goal with going Slack-Last is to minimize the sense of urgency for EVERYTHING, and put a more calm, thoughtful cadence to our work lives.  I say that and I’m not the developer…I can only imagine how scattered our dev team feels sometime.

Timelines

The Basecamp team has written much about how they work, and how that has evolved over time. In this article they talk about how they work in 6 week sprints, with 2 weeks after each interval for cooling off, refactoring, working on side projects, etc.  I love this kind of cadence to a development cycle, but for us as a relatively new/young team this is a bit long.

In 6 weeks a lot of things can and do change for a younger business, so we need the nimbleness to change on the fly.

So going forward the Castos team will be working in 1 month Cycles.  The interval will be broken down like this:

• New Feature Work: 75% of total time – here we’ll build awesome new things for our customers and improve on what we’ve already got working
• Bugs and Advanced Support: 25% of total time – at this point our bugs and really advanced support that our development team has to get involved with is pretty minimal and I’m hoping that 25% of our total time is enough here.

With this bit of flexibility added I’m hoping that we give ourselves the structure that there aren’t ‘too many’ unexpected things that come up and change our focus, but also that we’re nimble enough to meet the needs and expectations of our customers, without it just having to wait for the next month’s interval.

All bugs and support issues that need developer assistance will all be logged in Clubhouse cards under their respective Project, and will be given priority there if they are marked with our Critical tag. If there are no bugs or support issues that need a developers’ time then they are free to work on the features that we’re focusing on for this Cycle.

Cycle Planning

To pull this off will require a bit of planning up front, and coordination between myself and our developers as to where we are on existing projects, and what we think we can reasonably ship in the coming month.

Here at the end of March I’m putting together a list of all of the Stories we have in Clubhouse that are either in-progress, Ready for Development, or Unscheduled and will be organizing these into a new Milestone for the coming April Cycle.

This amount of work should be something that the team should be able to spec out, develop, test, deploy, and test again within the 3 weeks that we’re allowing ourselves in each Cycle (i.e. 75% of the month).

No doubt that this will be a learning process, primarily on my part as the person who owns the product experience on our team and is responsible for laying out what we work on next, but at this point we have a pretty predictable cadence to our development, so I think I can get pretty close here in this first month’s Cycle.

End of Cycle Call

At the beginning of each month we are going to have a single team call.  This won’t be the 10-minute standup type that’s so popular, but will probably be about an hour.  In this call we are going to cover 4 things:

• Talk about how things went last month
  • What initiatives went well
  • How timing went for each of the initiatives
• What the next Cycle is going to look like
  • What we want to work on
  • What business goals these initiatives help solve
  • Who will own each large project
• What our dev team needs from me
• What I need from our dev team

At the end of this call it should be very clear to me and our developers exactly what things look like here at the end of a month, and what the next month will look like for everyone.  Clarity, clear sense of purpose, and open roadmap for the next month going forward.

Workflow During a Cycle

Once the roadmap for the coming Cycle has been set the question becomes how do we communicate, update, and coordinate during this one month’s time?  We will be communicating almost exclusively in our project management tool, Clubhouse.

Each card will make its way across the board in the Kanban style that so many of us know from Trello.  Clubhouse of course supports file uploads, comments, linking to Github issues and Intercom messages (for linking development tasks to support issues), Creator of a card and Owner of a card, Deadlines, Tags, and a ton of other things that we use (and will use more of) to let everyone know where things stand (without having to give those awesome daily updates!).

We will heavily rely on these methods of updating the status of each Story we’re working on so that everyone on the team knows where your item stands.

As I mentioned before Slack has been mis-used, mostly driven by myself and my unorganized manner, to serve as an on-demand project management tool.  Going forward Slack will be used ONLY for clarifications that cannot wait for a response in Clubhouse, working things out together as a team in realtime, and as an avenue to discuss other non-development activities around work (like cat GIFs).

Measuring and Iterating a New Process

There’s no doubt that this won’t be a perfect process the first time, but I do know without a doubt that putting in the time to properly plan our work ahead of time, setting some expectations for me within our team, and giving them the freedom to know exactly what the next 4 weeks of work will look like ahead of time will create a much more productive and happy workplace.

I’m so proud of what we’ve built at Castos and Seriously Simple Podcasting already and hope that this new development workflow will only continue along this line of helping us create awesome new products and features, will let us serve our customers easier and quicker.

I’ll be providing an update as to how this process works and how we are iterating on this v1.0 of the process in our future development practices. So stay tuned…