It's been over 12 months since we shared some lessons learned on how we work. Octopus has nearly doubled in size since that post and this growth has introduced many changes. There are now 21 faces on our team page and we've adapted how we build and support Octopus Deploy.
Space
Octopus Deploy is based in Brisbane, Australia and most of our team lives here though we have a few team members spread around the world (Melbourne, Buenos Aires and soon Toronto). We mostly work from home but we also have an office in Brisbane's CBD/downtown area. The most immediate problem introduced by our growth was that the office was too small to fit the whole team. This meant we could no longer meet on Wednesdays and it heralded in a new way of working. We previously worked in sprints following a rough scrum approach and Wednesdays were our sprint review and planning day. It was the key day for collaboration and sharing as the whole team was in the office together. Once we couldn't fit comfortably in the office, the winds of change started. Paul shared his new vision that we would be shifting to an open allocation style of work.
Open Allocation
Open allocation at Octopus means that everyone has a lot of freedom in picking what they work on. Paul sets the overall direction and priorities but we self organise from that point forward. Teams spring up and people join the one that interests/suits them. Each team builds an agile inception deck to determine their purpose and how they want to work to deliver on it. Tasks and deadlines aren't assigned. We work together to figure out the best way to get things done. Open allocation builds upon the trust that is at the core of the way we work.
Small teams
It's funny that as we've grown, no one is sitting around without anything to do. If anything, it seems like we're busier now than ever. :) We recently shipped Octopus 3.4 and several small teams have emerged to tackle some awesome new work.
Customer Support AKA Team Awesome!
We have a dedicated customer support team that has recently doubled in size to four people. Customer support is very important to us and we aim to provide active, personable, and friendly support. Deployment automation is a large and diverse topic but we're here to help from download to deployment. We also have one developer on the team at all times and rotate this weekly. This helps everyone to get a better understanding of how our customers are using Octopus and some of the issues they encounter.
It's important to note that our customer support team is involved in the shipping new features from the start. Support is always represented at design discussions, feature demos and bug bashes as we believe no one understands our customers better than them.
Fire and Motion
Octopus has created a new team called fire and motion with the specific goal to continually make existing customers happy they chose Octopus and continually make our developers happy they chose Octopus and get to work with it every day. The name comes from an excellent article by Joel Spolsky. The 'fire and motion' idea comes from infantry battles where the only strategy to win is to fire weapons and move forward. It's all about making progress and moving forward. Writing code, fixing bugs, updating documentation etc. Reacting to competition is all about stopping your own motion.
We've adopted this idea in a big way to continually improve the day-to-day enjoyment of using Octopus. Historically, we have shipped feature releases every couple of months and then settled down into a period of bug fixes and enhancements until we start on the next feature release. We're changing this to have a team dedicated to improving Octopus for our existing customers. It's not all bug fixes though. There are some awesome enhancements coming too! :)
Feature Teams
Octopus started out as a friendly deployment automation tool for teams who work with Microsoft .NET and related technologies deploying to Windows servers. We added support for Linux as a deployment target in Octopus version 3.0 and this broadened our horizons greatly. While we're still primarily focused on Microsoft friendly technologies this group has expanded greatly. Personally, I think it's an awesome time to be a developer in the Microsoft space. Microsoft is opening up its platform to support Windows, Linux and macOS and they're expanding their Azure cloud platform faster than ever. This poses a challenge for us to keep up to date with everything but this is where our growth is an asset. We now can break into smaller, focused feature teams to tackle new technologies and infrastructure. One great example of this is .NET Core and Windows Nano Server including Docker support. We're actively working on adding a great story for Docker and the team working on this recently published a RFC (request for comments) blog post detailing how we're adding support. Watch this space for blog posts on more new features and how you can help shape them as they are developed.
We recently shipped Octopus 3.4 and it took us over 8 months to design, develop and ship the release. This was a bit of an anomaly because multi-tenant deployments was such a large and complex feature. We're aiming to shorten this period to get more awesome features to market sooner, rather than later. A great example of this is how we recently shipped new IIS Website and Windows Service steps including virtual directory support. This is a smaller release but we shipped them as soon as they were ready instead of holding them off for the next build feature release. Expect more of this in the future!
Daily stand-up
We've evolved our daily stand-up greatly over the last twelve months. Initially, we had a traditional company-wide standup over a Google Hangout each morning. As the team grew, we found this was becoming less and less relevant so we tried rotating the role of a standup 'cop' to help keep it focused. But we found this didn't really work either so we then tried an asynchronous daily standup using a #standup channel in Slack. The idea was that it could be a very low friction way to share what you're working on and any roadblocks. That said, each team is free to manage this further if they find they need to sync up on technical issues or work in progress. We've been doing this for most of the year and it's been working really well. Everyone can easily keep up with what other teams are doing it doesn't take a lot of time.
The right tool for the right job ...
We continue to adapt the tools we use to communicate and get stuff done. If we find something isn't working and it's a common theme, then we look at changing it.
We still use Slack, Waffle.io and Google Hangouts but we've recently added Bluejeans and Trello to improve our product development.
Slack
Slack is still our primary communication tool but we've changed the way we use it. When I joined Octopus, we used Slack for everything and everyone belonged to nearly every channel. We were very chatty and everything was wonderful. Then, we found that most people were constantly trying to keep up to date with notifications, day or night and it wasn't healthy. Other teams have written about dropping Slack completely but we decided to declare Slack bankruptcy and change the way we use it. We removed a lot of noisy, irrelevant channels and everyone was encouraged to only join the ones that were relevant to them. This has made Slack a much better tool and we don't feel a need to constantly check for notifications.
Adding Bluejeans
We use Google Hangouts all the time for distributing meetings and adhoc face-to-face conversations but we found getting private recordings of Hangouts to be a hassle. So we did some digging, asked some friends and found Bluejeans. Bluejeans has a great video communication product that works across platforms and has easy and fast recording and playback. We trialled it and found it worked pretty well so we added it to our toolset. We still use Hangouts for quick meetings but if it needs to be saved or shared, then we use Bluejeans and it just works.
Adding Trello
Trello is a fantastic service to help organise and manage information into lists. We used it in the past to capture and priorities bugs in bug bashes but we've started using it a lot more in our small teams. It's so fast and flexible, it's a very simple way to manage project work as it moves towards release. We generally use it in a kanban style to reflect work in progress and move things to the right. We also have a 'home' board which shows all the company activities in progress at a glance. This makes it easy to stay on top of things happening in other teams without the need to jump into their team specific board.
Wrap-up
That's it for this instalment of how we work. Things are running pretty smoothly at the moment but we're still learning so they'll likely change again. The end result is shipping high quality releases more regularly and making our customers happy!
I hope this was an interesting look into how we build and support Octopus. Feel free to add a comment to share any changes your team has made or a cool new tool that helps your team communicate better.
