{"id":1153,"date":"2020-10-30T08:57:56","date_gmt":"2020-10-30T08:57:56","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1153"},"modified":"2020-10-30T08:57:58","modified_gmt":"2020-10-30T08:57:58","slug":"towards-business-agility-2-0","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2020\/10\/30\/towards-business-agility-2-0\/","title":{"rendered":"Towards business agility 2.0"},"content":{"rendered":"\n
\"\"
Photo by Marc Sendra Martorell on Unsplash<\/figcaption><\/figure>\n\n\n\n

Soon after the introduction of agility in software development, the notion of business agility was introduced as well. The basic idea was to scale the concepts behind agile software development to larger scopes, with the ambition to reach the entire organization, including R&D and IT. In practice, however, for many organizations, it proved difficult to go beyond the software part of the organization and things often got stuck at DevOps. Also, the basic mindset often was to treat changes as disruptions in a steady-state system, focused on returning to a steady state as soon as possible. Agile was concerned with minimizing the impact of changes by rapidly responding to them. The notion of business agility was very popular around 2010 and then started to fade as it didn\u2019t provide the benefit that companies were looking for. To quote a manager in one of the Software Center<\/a> partners: \u201cWe use SAFe and say we\u2019re all agile but we didn\u2019t change a thing\u2026\u201d<\/p>\n\n\n\n

More recently, we can see a development that\u2019s not entirely \ndissimilar to the first incarnation of business agility (1.0) but that \nhas a number of unique characteristics and is leading up to a 2.0 \nversion of business agility. This version has, at least, three unique \naspects: business models, technology scope and fast feedback loops.<\/p>\n\n\n\n

First, many companies have started to realize that agility at the \nbusiness level starts with the business model that you employ. It has to\n start with a transition from a transactional to a continuous model. If \nyou build the capability to deliver value to customers but don\u2019t have a \nway to monetize the continuous value capture, there\u2019s no business \nincentive at all. If you improve the product, system or offering along \nsome dimension, you need to be able to capture some of that value. For \ninstance, if you run a truck company and you conduct A\/B testing on the \nengines of your customers in the field to improve fuel efficiency, you \nwant to capture some of the savings that your customers are enjoying. \nWhy else would you bother with experimentation in the first place? So, \nwhereas business agility 1.0 started bottom-up with the software \ndevelopment teams, the 2.0 incarnation starts top-down from the business\n model.<\/p>\n\n\n\n

Second, in the embedded-systems industry, there\u2019s a growing awareness\n that continuous deployment or DevOps doesn\u2019t need to be limited to \nsoftware. Under the right incentives and business models, it\u2019s entirely \nfeasible to periodically update electronic and mechanical parts of \nsystems in the field to improve system performance. Among others, Tesla \noffers chip upgrades and hardware retrofits providing significantly \nimproved capabilities, which the software can then use to improve the \nfunctionality in the car. So, business agility 2.0 doesn\u2019t just focus on\n software but extends to electronics and mechanics on the one end and \nincludes data and AI on the other.<\/p>\n\n\n\n

Third, the focus in business agility 2.0 is on fast feedback loops \nacross the company and all technologies. This has two aspects. First, \neach technology has an optimal feedback length where the customer and \nbusiness benefit of new releases are balanced with the cost of \nmanufacturing, distributing and installing. This of course means that \nsoftware (including AI models) can afford to have very fast cycles as \nthe cost of distribution and installation is very low and there\u2019s no \nmanufacturing cost. For electronics, especially when keeping the \nmechanical interface constant (pin configuration, power usage, EMC, and \nso on), the cost is higher and perhaps a yearly or biannual cycle makes \nthe most sense. Finally, for mechanical parts, the update frequency \nshould be even lower as they\u2019re even more costly to manufacture, \ndistribute and install. Still, when the continuous business model has \nliberated you from the \u201clet\u2019s save all improvements for the next \nproduct\u201d attitude, also improved mechanical parts can be distributed, \nsay, every three to five years.<\/p>\n\n\n\n

\"\"\/
Business agility 1.0, digitalization and business agility 2.0<\/figcaption><\/figure>\n\n\n\n

The second aspect is that no slower cycle can slow down the faster \ncycle. Traditionally, the software release frequency was bound to the \nproduct release cycle. In business agility 2.0, no faster cycle \n(software or electronics) can be slowed down by a slower cycle (eg \nelectronics or mechanics).<\/p>\n\n\n\n

We\u2019re entering the era of business agility 2.0, which starts from the adoption of a continuous business model and then optimizes the entire company to capitalize on fast feedback loops that allow for all technologies in products to improve at their own pace. Even if your customers aren\u2019t asking for it yet, your suppliers are complaining and your partners aren\u2019t yet ready to play ball, you better get going on this as the second incarnation of business agility provides major benefits, as well as improvements in efficiency and effectiveness that you can\u2019t do without. Go agile, but go 2.0!<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at <\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>) or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Soon after the introduction of agility in software development, the notion of business agility was introduced as well. The basic idea was to scale the concepts behind agile software development to larger scopes, with the ambition to reach the entire organization, including R&D and IT. In practice, however, for many organizations, it proved difficult to … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[3,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1153"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1153"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1153\/revisions"}],"predecessor-version":[{"id":1155,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1153\/revisions\/1155"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}