A quick intro before I get started: Hi everyone. For those of you who don’t yet know me, my name is Chris Iona and I’m the new product development manager for BigCommerce. You can read Mitch’s introduction post here if you like. Today I’m going to talk about Agile – the methodology we’ve been using almost since day one to improve BigCommerce at a rapid rate. If you have any comments or questions, feel free to leave them below and I’ll be happy to reply.
This is the first of many posts I’ll be contributing to the blog moving forward, so, let’s get into it!
Here at BigCommerce, we’re constantly challenging our people, product and performance – three important factors in any successful company.
So it should be no surprise that having started my career in Customer Service, I know just how important it is to get it right the first time. The better we can deliver on BigCommerce, the more exceptional the experience is for you, your customers and our staff. It’s a win-win-win scenario, and one of my major drivers as Product Development Manager.
One thing I think we’ve done right from the beginning, is invite you, our community, to help drive the features and enhancements we work on. Of course like most things in life, there’s a delicate balance that needs to be met – in our case, it’s between new features, enhancements, capability and bug fixes.
So how do we balance the development needs of BigCommerce? You guessed it, Agile – which is something that’s received a lot of attention lately, but is not a new concept. Don’t believe me? Just ask a football player or boxer why it’s so important to be light on their feet. The ability to react instantly to any change (pace, position or play) can be the difference between losing at the last second and enjoying a career-defining win. Developing software is really no different.
A sprint is a short, defined time frame where we complete a list of tasks (called scope). These intense, short bursts of work, allow us to clearly focus on a small amount of tasks at a time – which is why they work so well in keeping us Agile (I’d suggest reading about Millers Law of 7 ± 2).
The problem we faced with having only one sprint per fortnight, is that it doesn’t account for any urgent or high impact bug fixes reported by our clients, community or staff. Agile is a framework, and each company needs to make it work for them. So what we’ve done is run two sprints at once – a core sprint, and a maintenance sprint. I should also note that the key premise of a sprint is to have a working build at the end of the cycle, and not necessarily something that we release. We may go two or three sprints before we release a core update to production.
Our core sprints operate for two weeks, and consists of new features, enhancements, bug fixes and capability (I’ll explain capability later on). Our maintenance sprints operate for several days, which means we can get urgent or high impacting patches out to your store rapidly.
I firmly believe that capability is contextual. That is, something that’s of high importance to our sales staff, might have lesser importance to the development team – which is exactly why we’ve built “capability” into our core sprints.
Every core sprint, we dedicate 20% to “capability tasks” for features or improvements requested by our sales, support and engineering teams. They’re just as important to them, as the requested community enhancements are to you. What this gives us is a text book continuous improvement process, resulting in quicker resolution of support trends, improved tools for sales, and much better code stability. Providing everyone with a sense of ownership and empowerment, means better software and a stronger community.
Now for the daily scrum, which are also known as “Stand Ups”. Every day, the engineering team meets to discuss what we’ve achieved, what we plan to achieve, as well as to address any constrains, issues or blockers. Without this strong communication, the success of a sprint is in jepardy – so much so that there will be times where we’ll hold stand ups twice a day.
Introducing process and structure is a good thing, but it’s important to remember not to cramp the style of your engineering team – something that I’ve learnt during my career. It’s impossible and impracticable to shoe horn everyone into a set mould, which is why we’ve introduced “Other Time”. Other time makes up 20% of our developers day, where they can catch up on outstanding work, hold meetings, complete code reviews, prototype a new idea, or go grab a(nother) coffee – we drink A LOT of coffee here!
So in conclusion, we’re using Agile to respond to new feature requests, ideas and changes quickly, concisely and in a structured manner, with the ultimate goal being to make BigCommerce better for you, your customers, and also ourselves.
You might ask why I’m being so open and honest about how we are doing things around here? Not only is it the way that I like to manage, it’s a part of our Mission and Values – which we live by.
One thing we’ve been working hard on as a company over the last few months is defining our mission statement and core values. I believe that as a company we have a fantastic culture, and it really sets us apart from everyone else. One thing Eddie and I wanted to do was take our culture and “bottle it” so to speak. We wanted a way to summarize how we think and act as a company into a few short sentences which everyone can use and live by.