Speed, not haste, in feature delivery

When it comes to programming, many of us are divided on the perception of the word “ ”. Some argue that speed kills innovation and creates an environment which feels like you are always ‘firefighting’. speed In this blog post, I want to point out that there’s a difference between and . And that if done right, speed can be a really powerful exercise. The myriad of advantages that we have come to benefit from at is what inspired me to share my thoughts with you. speed haste practicing speed Squad Here are a few of those key points - Higher team morale I consider a boost in team morale as one of the best benefits. When I say team, I don’t just mean the development team but also the newly established ‘solver teams’ at (the concept of which is beautifully explained by the folks over at Spotify). Squad here Continuous Delivery for Speed Work never gets monotonous when improvements and everyone on the team gets to work on new things since the product keeps maturing at a faster pace. ship fast Also other teams (like ops and sales) don’t have to wait for the next deployment window to expect a small new feature. In fact, they can request a feature today and get it by the next day (only for critical priority features, else it gets added to the backlog). (Read for a more in-depth insight on the culture at Squad) Squad takes the Joel test Faster development and bug resolution Shipping fast means deploying features in small releases instead of a big hefty release. Since the releases are smaller, things can be quickly tested and fixed instead of testing an entire release and then spending a considerable amount of time figuring out why a bunch of bugs came out. This is also why Squad does not have a . Each developer is responsible for their own release and things are rigorously tested in the staging environment before shipping. QA team If you have had experience working with a large team, you would know that the shipping and fixing cycle consumes more dev time than the actual feature development. Smaller releases eradicate that to a large extent leading to more feature-development-time and less bug-fixing-time, consequently boosting the morale of the dev team. I mean, who wants to fix bugs right? We all want to keep building. After all we are engineers. Better product quality Addressing the bugs and any feedback instantly keeps the product quality high. Bugs don’t get backlogged and any major/critical issues get addressed immediately. Which means a stable product. Who knew speed could impact product stability? Much better UX Shipping features in a big chunk enforces the users to adapt to a lot of changes in a short span of time. Sometimes the changes can be so drastic that your customer success team needs to guide users on how to adapt to these changes. On the other hand, when you regularly keep shipping small updates, your users don’t need to take in big surprises all at once. It’s not a different product for them on a new day. For them, the product keeps improving every day. Another major advantage is that if users have constructive feedback for a feature requirement, we can develop and ship it quickly in a matter of days. Nothing says “we care” better to the user, than taking her feedback seriously by acting on it quickly. You may have just earned a loyal customer. Better reprioritization With all the user feedback and suggestions coming in to help evolve your product in the right direction, sometimes something does strike as the perfect value addition to the product and you want to build it right away. It’s a tough situation when your team is already geared up with the tasks for the and any changes might affect the sprint end release. But not if you are always shipping. As soon as the next feature gets released, you can prioritize the new task and get it building while still achieving the sprint goals. sprint No holdups Our every release is independent so that a developer does not have to wait if something breaks in someone else’s code. This means code which is good to go does not have to wait in line for other code. We do sometimes have multiple features in the same release but they’re just parts-of-a-whole that are still entirely capable of being broken apart from the rest, in case something goes wrong with one of them. Each of the features can be independently pulled back and the rest of the release can still be shipped. At this point you might be thinking that this all seems so perfect. Maybe too perfect. Are we actually achieving all this? To which I’d reply, . mostly yes We are a and we learn from our mistakes and experiments. These points are what we have experienced, things that worked for us and might work for you as well. Some experiments fail and may not end up seeing the light of the day but that’s what it’s all about — learning from failures. Tweaking your strategy and trying out new experiments. Looking out to what may work and help us grow. learning team Fancy working in an environment that encourages shipping products fast?. We’re hiring .