thredUP operates in 2-week sprints. This means that every two weeks teams are either transitioning to or already working on their next project. Personally, I love this project management methodology and would urge other teams/companies to look into this strategy for a variety of reasons. Since I didn't create this idea and am not in the position to make strategic decisions of this nature, I'll only give you the perspective of someone on the ground floor working in sprints and how it impacts my work-flow on a daily basis. So if you're in the power to make these kinds of decisions at your company, here is why I suggest you do so or at least entertain the possibility.
First, let me quickly provide some context for the term sprint with a brief background of its origin. Sprints are a key component of Scrum development. I'm not 100% positive it is the reason why we do sprints here at thredUP, but since the dev team has 'scrum' meetings every morning, I think it's safe to assume that 1 + 1 = 2 in this situation. Scrum is a highly iterative and agile development project life-cycle strategy. Plan out the sprint, break-down who will be doing what, then get your hands dirty. It's pretty fun. I like to think of it like a 3-man weave in basketball. For those not familiar with the term, it's when 3 people pass the ball back-and-forth down the entire length of the basketball court without ever dribbling. From a distance, it looks like three people running very fast bobbing and weaving across a court and eventually ending with a simple lay-up. You never hold onto the ball long enough to dribble and slow down. You never get the chance to over think what you're doing - execute and react, it's that simple. You rely heavily on your team members and timing and this is why I think it is very similar to the ebb and flow of a sprint. At the end of each sprint you evaluate, plan how you will iterate accordingly, and then plan out the next sprint. Rinse and repeat.
For a real-world application of how this works, we recently released the ability to become a ;thredUP military member, a member role that is eligible to receive additional benefits. This project touched many areas of our application and in result the project was broken out into several smaller tasks that could be assigned to small groups of team members and tackled quickly. Back-end, front-end, design and marketing all worked together to roll this out in two weeks. By breaking into small groups and assembling teams from different departments, it allows us to provide quality results in a short time frame that cover all angles of a project. When you work closely like this, everyone is exposed to every facet of the project and therefore the feedback is immediate. You can iterate and pivot at a much earlier point in time when everyone is banging (heavy testing/usage) on what you're working on. So your individual projects are agile in that sense. If you take a step back and look at all the sprints and your product from a broader level, you're agile there as well. All of the individual sprints are little cogs in the product and you can assemble and move around pieces very easily.
The flip side of is would be if you spend months developing a big iteration or feature of a project. You'll end up banking that it will be a success because if it fails, you will have wasted a lot of time and resources. I hate to throw one of my favorite websites under the table, but Digg v4 is a great example of this. Digg spent what seemed like 6 months to a year preparing the roll out of their new design, interface, feature set and back-end implementation. Complete overhaul. All the apples in one basket. How did it turn out for the once powerhouse crowd-sourced news aggregator? Well, within 2 months of launching v4, the CEO, CFO, and CRO (Chief Revenue Officer) have all left their positions. As if that wasn't enough of an indicator, Digg laid off 37% of their staff (plug: thredup.com/jobs), lost over 20% of their traffic, and they have already started reverting back to some of the previous version's functionality they took away. I think Kevin Rose is a talented entrepreneur and I believe he can help Digg bounce back and when they do they should really try out Scrum. If they would have iterated and released earlier, the backlash from users would have occurred at a much earlier stage and the agility of Scrum would have allowed them to adjust and avoid the downfall. I could go off into a monstrous data-driven development rant and why it's so important but I'll save that for another day.
So Scrum is solid from a business point of view, but why would your employees or me for that matter enjoy this as well? I'll break out my rationale into a list:
- You never get bored. How can something get old if you don't spend more than 2 weeks on it?
- Goals and milestones are actually attainable. Every day I can reach a significant milestone if 10% of the project's time passes by every day. These tangible goals are motivating and leave no room for procrastination. There's never a point where you think to yourself 'no one is going to see this for another 3 months, today doesn't really matter'.
- The energy levels are always high. New projects and ideas are always right around the corner and the creativity is contagious. Boredom is canceled out by this energy and since boredom and productivity have an inverse relationship, everyone is always churning out results.
- Developing inter-personal skills and relationships with co-workers is an excellent by-product of sprinting. You learn new tools and skill sets from working closely with team members and you enhance your ability to explain/write code that can be easily built upon. There's also the added benefit of developing an excellent rapport with your co-workers.
- There's no pigeon-holing. You have to turn into a Swiss army knife and be comfortable attacking any component of a feature. It allows you to be more versatile in future projects.
Hopefully this post illustrates why I find sprints as motivating and productive as I do. Honestly, I can't imagine ever going back to a traditional product life-cycle after dipping my toes in Scrum development.
Dan
Front-End Developer and Ruby on Rails Newbie
dan@thredup.com