We recently had a question come in from one of our awesome customers, on top of saying some really nice things about us (we love feedback like this) asked :
"I'd be fascinated to know what kind of tools and methodologies you use to keep everything running so smoothly?"
About six months ago Paul blogged about How We Work, but we're still a small team, and one that's not afraid to try new stuff, so things are always changing.
Here's a peek inside what's been happening here, what's changed and a couple of lessons we've learned along the way.
Scrum and Chaos
Not all that long ago we had a process, loosely based on Scrum, that had us with something potentially shippable every two weeks.
Then we did the thing that we work hard to help you not do... and that's go 8 months without a major release!
When you do that, it means that while you're getting things done and building features, there's a big, un-quantified amount of "stuff" to do. I'm sure you've been there, where you're 90% done yet somehow the last 10% of finishing touches takes 90% of the time.
It's the problem of working without a proper time box. Many teams that try Scrum but don't ship to production hit this too. Without a hard deadline it's easy to become a bit complacent and leave a few unfinished corners.
To be fair though, we were tackling a massive amount of architectural changes at once, and trying to get everything working with everything at once would have been fairly wasteful.
Deadlines, Bug Bashes, Swarms, and Kanban
We used a couple of things to dig us out of this. We set a date for our pre-release and looked at what we needed to get us to that point.
We do something we call a "bug bash" fairly regularly now. We all install a build and spend an afternoon trying to break it in every way we can. We look for bugs, inconsistencies, usability issues, and anything else that would impact the experience. We store it all somewhere lightweight like Trello.
So with the pre-release in mind, we did this and got to work on fixing them one at a time. This means we had a very limited work in progress, and we all worked very closely to get everything moved across our Trello board and into a build.
Once we hit public pre-release we kept this up, and released a number of builds and did constant swarms on the issues on our board to get them fixed quickly and into a new build.
Continuous Delivery
As Paul said last week, we're trying to keep this sort of momentum up and ship a lot more regularly because it does a few things. It keeps us focused on "Done", and it helps make Octopus Deploy a bit better every day. If we (or a customer) find a bug, why should we knowingly keep shipping that bug to everybody that downloads our product for two weeks if we can ship a fix the next day ?
We've been doing some fun stuff to automate a lot of our release process which we'll start to share soon too.
Smaller Teams, shorter stand ups
When we were smaller, it made sense for everybody to be across everything, and we all worked in one Sprint. In more recent months though we hit a point (familiar to many) where our stand ups were unfocused, and you'd often need follow up conversations to actually plan your day. But we liked actually seeing everybody's face in the morning so we didn't want to drop them all together.
So we split up into smaller teams and have more focused stand ups for each.
You see, while our 3.0 release was happening, we also rebuilt a bunch of our website. We changed the design, moved off RavenDB and on to SQL Server (using the same library we wrote for the product, we'll probably open source it soon), moved it to Azure, and made a bunch of other changes.
Because we're shipping both things more regularly, the stand up is a lot more about "what do we need to do for the next release", which is a lot more focused than the standard "what I did yesterday, what I'm doing today" type questions.
People often join the hangouts a few minutes early too, so we can have a chat and shoot the breeze.
Weekly Review and Planning
We try to all be in the same room every week for a review and planning. This isn't overly formal, anybody that has something notable to show does a short presentation, demo or discussion. Later in the day we'll split off to look at priorities for the next week and discuss anything that requires a group. This helps us all be on the same page about what we're doing and why.
Tools for a distributed (or not) workforce
While we're mostly all in Brisbane, and we have an office, we still work from home a lot. The tools we use for this change a bit, but it's the fun bit everybody wants to know about.
Slack
We love Slack and use it for almost everything. All of our other tools pipe their messages into it so it's the constant pulse of our company. It's a great tool for collaboration within the team. It can get a bit noisy, but you can always close it down for a while then catch up on the history when you get back online. If somebody needs you, a mention of your name can turn into a notification on your mobile device of choice so it really gives you a lot of flexibility in how you work. The ability to add your own emoji is fun too!
Google Hangouts
We've been using Google Hangouts for a while, but we're using it more and more. There often comes a point where text chat isn't working and we've become very good at recognizing this and jumping to a Hangout. I think this is the trick to working in a distributed way, knowing when to escalate to a higher fidelity communication medium.
Waffle.io
This is the newcomer to our tooling arsenal. We use GitHub for our code and issues and previously we used HuBoard to get our issues in front of us as a taskboard. HuBoard is good, but we've found a Waffle.io is a little better for us. Through some GitHub web hooks it gives us a realtime, two-way sync between the board and GitHub (working directly in GitHub is easier for a lot of things, and HuBoard would need a refresh to pick up the changes). It also has a great feature to link Issues and Pull Requests on the board which move to a "For Review" column.
Lessons
They say that one of the most dangerous phrases in business is "But we've always done it this way". It's very important to be able to see that something isn't working and make changes to it. This is our latest iteration of "how we work" and as time goes on I'm sure it will change again.
Some other lessons to take out of it are that shipping forces a focus on getting things done, shipping often really ingrains that focus in your team. The inverse of that is that working on too many things at once removes the focus from shipping, which makes it harder to do.
Correcting that and "swarming" to get back on track is a great way to turn your team around.
