Agile & Velocity: Adapt or Die
One does’t do Agile. One becomes Agile
- Quick and well-coordinated in movement;
Some of the world’s most revered champion MMA fighters and professional boxers have defeated larger and often faster opponents by learning to be agile on their feet. Agility in this sense equates to a potent mix of speed, timing, reflexes, and coordination. World heavyweight boxing champion Muhammad Ali is most notably quoted for the phrase: “Float like a butterfly sting like a bee”. This quote highlights his keen awareness of how important agility is during the course of a boxing match. Experienced fighters know that for a fighter to be effective he or she must possess agilit
y to efficiently react to incoming offenses, respond properly with feigns and fakes, and counter an opponent’s offenses effectively. In the business of software development, delivery, and operations outmaneuvering business competitors is in many ways similar to a boxing match. The most effective contender in this context wins the market share. The winning organizations ability to react to incoming issues, outmaneuver their competition, pivot on customer needs, and adapt to real world issues are critical for success.
Prior to the popularization of cloud computing, Docker containers, [HA] high availability, and zero downtime deployments, SaaS businesses would conduct risky “big bang” release ceremonies (usually at 2am or some other god awful hour). Such ceremonies were massive in size, riddled with defects, and often ended with a complete rollback on the production environment. Once the release finally was deployed, hotfix deployments would monopolize engineering resources until the system stabled out. Agile software development was follo
wed by DevOps, and eventually CI->CD; all in an effort to reduce batch size, lower the risk in releases, increase release frequency and save workers from the dreaded 2am release ceremonies. As of 2016 however; there are still numerous organizations that conduct the now infamous late night production rollouts and risky big bang releases. This is not from a lack of interest in decreasing risk but rather a failure to apply a practical increase in velocity.
Velocity: The art of mastering throughput and speed
Rapidity of motion or operation; swiftness; speed
Velocity in an agile development context has a single aim – to increase the throughput of engineering and get working software into stakeholder’s hands earlier. This means delivering value to the customer more often and pivoting implementations based on critical feedback provided. To increase delivery throughput the primary requirement is to reduce code and feature batch size. A batch in this sense is the fragment(s) of code being delivered to the customer.
Decreasing the batch size has a number of implicit and explicit business benefits. The most obvious benefit to the business is an increase in the frequency from which the business can retrieve financial value from invested the software system delivered. Rather than waiting 6 months (or more) for a given “release” to be completed, features can be delivered to revenue generating customers in smaller segments. This allows the customers to digest changes to the software incrementally and provide feedback on the usefulness of the software. In addition, the business can alter its trajectory based on customer demand for features and reduce wasted development efforts on features not deemed valuable.
The practical implications for the development organization (related to shrinking batch sizes) can be significant as well. By reducing the batch size, development will inherently need to reduce the size of specific implementation requirements (stories). This will allow developers to reduce the complexity of implementations and focus on smaller targeted changes. In addition to a reduction in complexity; reducing the batch size, will also increase overall developer productivity. This is increase in productivity is summarily due to the fact that developers can better grasp what is required of them. As a result late night rushes and weekend efforts to complete “sprint” work are more likely to become the exception and not the rule (due to better scoping and time management). Finally when reducing batch size, the likelihood of encountering time consuming technical challenges and struggling to perform defect identification is also likely to be reduced. The reason is simple; the less code changed / the easier debugging session.
Within the realm of QA, Quality assurance engineers also gain value from a reduction in batch size. QA engineers now have the bility to avoid performing a complete regression and acceptance test cycle on every change. With manual QA efforts reduced a focus at this point can be placed on automating test cases, validating new alterations to the software and ensuring features contain fewer defects.
For operations folks; determining the root cause of an outage can be a daunting challenge. This challenge is exponentially magnified when the most recent deployment contains large alterations to code base and numerous interwoven working parts. Reducing the batch size can save our operations friends a significant amount of headache when supporting the software systems we create.
Generally velocity can be increased when complexity and the number of ancillary dependencies decreases. These are important prefixes to moving faster. In an effort to increase velocity have a number of smaller autonomous teams that can independently deliver value should be valued over a monolithic team with numerous connected dependencies.
“If an engineering or operational task is painful; the most efficient way to address the pain point is to do it more often. This will alleviate the pain and convert the once painful procedure into a mundane exercise. Mundane is EXACTLY what we want. “ – Etsy
Organizations that have embraced a “higher velocity” and more agile approach to software development and delivery have realized significant financial rewards. By taking an #adaptordie approach Etsy.com [quoted above] effectively vaulted its gross sales portfolio from 238million in 2012 to 2.388 billion in 2015 by embracing a reduction in batch size, the adoption of DevOps practices and an agile mindset in whole. Netflix ambitiously managed to spearhead the micro services space and now practices continuous delivery at a massive scale. With a low stock price of 8.99$ in 2012 Netflix has been the come back kid of video streaming and since become the world’s premiere video content service provider with an elevated stock price of over $99.00 by mid 2016. These two companies are not exceptions to the rule either. Other organizations have followed suit and are worth a notable mention. They include the following:
Organizations that fail to adapt to a continuously changing business world and are slow to react often fail to outmaneuver their competition. Ofcourse there are exceptions to this rule but the general idea is sound. This error in business agility can lead to large financial and social losses. Many rigid organizations have faltered, failed to adapt, and eventually died. Such examples include:
- Circuit City
- Pan AM
Increasing velocity in the delivery space will insight fear and doubt in the eyes of old timers used to previous practices. But if we are to overcome the traditional mindset and move into the future of software we will need to adapt or we surely will die. Change can often be very difficult to embrace (let alone advocate for) but it is by continuously reinventing ourselves that we remain applicable in the current market.