{"id":1117,"date":"2020-08-18T19:01:24","date_gmt":"2020-08-18T19:01:24","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1117"},"modified":"2020-08-18T19:01:39","modified_gmt":"2020-08-18T19:01:39","slug":"planning-for-business-agility","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2020\/08\/18\/planning-for-business-agility\/","title":{"rendered":"Planning for business agility"},"content":{"rendered":"\n
\"\"
Photo by Kelly Sikkema on Unsplash\n<\/figcaption><\/figure>\n\n\n\n

During the summer, I reflected on the main differences between software engineering in the 1990s, when I became a professor, and today. The best way to describe what I feel is the key difference is perhaps through an analogy. In the 90s and early 2000s, software engineering was akin to designing and building a jet engine first. Once you felt you had a good engine, you\u2019d hook it up to a plane and let the plane fly with it. These days, you design and build the \u201cminimal viable engine,\u201d get the plane flying with it and then start tinkering with it through continuous upgrades (DevOps), experimentation (A\/B testing) and automated experimentation by the system itself (online learning, reinforcement learning, etcetera).<\/p>\n\n\n\n

By and large, I think this development is really good. I\u2019ve often \ndescribed the traditional way of system development, where we\u2019d spend a \nyear or more building to a specification, as similar to pointing your \ncar as accurately as possible towards a light at the horizon, closing \nyour eyes and putting the pedal to the metal. Anyone who takes a step \nback to reflect on software and system development realizes that any \nsystem, including an R&D system, needs a feedback loop and constant \nadjustment. The whole notion that we can build a system based on specs \nthat are a year or more old and expect that the results are exactly what\n the customer wanted is one of the fundamental fallacies in engineering.\n The rule of thumb in software engineering is that requirements change \nat a rate of 1 percent per month.<\/p>\n\n\n\n

The risk associated with sprints, continuous deployment (DevOps), \nDataOps, MLOps and the like is that we never lift our eyes beyond the \nimmediate next sprint. Teams become reticent to take on any task that \ntakes longer. Product management focuses increasingly on the small \nimprovements that can be accomplished in one sprint. The entire company \nincreasingly falls into a reactionary pattern where customer requests \nthat fit in the sprint mindset are all that get prioritized and the \norganization loses control over its own destiny.<\/p>\n\n\n\n

The consequence of this is, of course, that the company accumulates a large amount of debt. This debt includes technical debt, e.g. architectural and infrastructural, but also strategic debt, as there\u2019s no North Star to guide the organization by, as well as process debt, as process improvements are typically not prioritized in these organizations. The adage of \u201cfailing to plan is planning to fail\u201d once again proves true.<\/p>\n\n\n\n

Most companies that I work with recognize this challenge in some form\n and seek to address it. Quite some, unfortunately, reach the wrong \nconclusion: they let go of Agile practices in R&D, product \nmanagement and so on, and fall back in the old, waterfall style of \noperating. This is a fundamental mistake that might easily kill the \ncompany: Agile practices in the organization are intended to support \nbusiness agility. In a fast-changing world, where the future is hard to \npredict, business agility is one of the most important characteristics a\n company can have.<\/p>\n\n\n\n

The better way forward, in my experience, is to separate planning and\n execution: we want to plan long-term and execute short-term. This means\n that we plan system functionality, architecture refactorings, \ninfrastructure changes, process improvements, innovation efforts and so \non for a longer period (quarters and years), but we execute those plans \nin sprints and allow for constant adaptation based on changes in the \nenvironment, the company and the market.<\/p>\n\n\n\n

In several cases, I\u2019ve noticed that, especially traditional, managers\n gather quite a bit of comfort from creating plans and then executing \nthem come hell or high water. It provides a sense of being in control of\n what might otherwise feel like a chaotic situation. What the Stoics \nteach us, though, is that most of the things in our lives that we think \nwe can control are completely outside of it. Nobody could have predicted\n the Covid-19 situation, nobody knows when the next economic recession \nor even depression will hit, nobody knows when the next technological \nbreakthrough is putting our company at risk of disruption. We don\u2019t even\n know whether the stock market goes up or down tomorrow! Instead, we \nneed to respond to the things we can\u2019t control by focusing our energy on\n the things we can.<\/p>\n\n\n\n

Concluding, the world has moved from planned and offline to real-time and online. The risk is that we lose track of the long term in favor of an overly strong sprint focus. Rather than giving up on Agile practices, we need to complement agile execution with systematic, long(er)-term planning to garner the best of both worlds. It allows us to control the destiny of our company while responding to the societal and industry changes that we don\u2019t control. Agile with purpose!<\/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":"

During the summer, I reflected on the main differences between software engineering in the 1990s, when I became a professor, and today. The best way to describe what I feel is the key difference is perhaps through an analogy. In the 90s and early 2000s, software engineering was akin to designing and building a jet … 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":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1117"}],"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=1117"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1117\/revisions"}],"predecessor-version":[{"id":1119,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1117\/revisions\/1119"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1117"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1117"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1117"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}