{"id":1066,"date":"2020-04-15T12:09:23","date_gmt":"2020-04-15T12:09:23","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1066"},"modified":"2020-04-15T12:09:29","modified_gmt":"2020-04-15T12:09:29","slug":"why-agile-matters","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2020\/04\/15\/why-agile-matters\/","title":{"rendered":"Why Agile matters"},"content":{"rendered":"\n
\"\"
Image by Dirk Wouters from Pixabay\n<\/figcaption><\/figure>\n\n\n\n

Recently, I got an e-mail asking me why we should care about Agile if the overall product development process, including mechanics and electronics, is measured in years and is completely waterfall. The question took me by surprise. I\u2019ve been working with Agile practices for the better part of two decades now and for me, it\u2019s a given that fast feedback loops are better than slow ones.<\/p>\n\n\n\n

However, after more careful reflection, I realized that the question \nis based on a few assumptions that, in turn, are founded on our beliefs \naround our ability to predict. The first assumption is concerned with \nour ability to optimally predict requirements for our products months, \nquarters or years down the line. In many industries where products \ncontain mechanical and electronic components, the production pipeline \nrequires long lead times. Consequently, the product requirements are \nformulated long before the start of production. The fallacy is, of \ncourse, that requirements change all the time due to new technologies \nbecoming available, changing customer preferences, actions taken by \ncompetitors and so on. One rule of thumb in software says that \nrequirements change with 1 percent per month \u2013 a very conservative \nestimate if you ask me.<\/p>\n\n\n\n

So, how to respond to constantly changing requirements? There are \nfundamentally two approaches. Either you adopt agility and continuously \nrespond to changes or you resist requirement changes, reject all that \nyou can and grudgingly accept those that you really can\u2019t ignore. The \nresult of the latter approach is, of course, an inferior product as it\u2019s\n based on the best insights from years ago.<\/p>\n\n\n\n

The second assumption is that we can predict the effect of our \nrequirements. These are defined as we hope to achieve a specific outcome\n as a consequence of realizing the requirement. We see this most often \nwith usability requirements, but it basically extends to any quality \nattribute of the system. Online companies use A\/B testing of solutions \nto determine the effects of different realizations of functions and \nfeatures on users. These companies don\u2019t do that because they\u2019re so poor\n at requirements engineering, but because the effect of features and \nfunctions is fundamentally unknown when it comes to the way humans \nrespond to software functions.<\/p>\n\n\n\n

Traditional engineering companies pride themselves on their ability \nto predict the capabilities of systems before they build them as \nengineering offers a set of mathematical tools for modeling, simulating \nand predicting. These models are typically then confirmed by lab tests \nand in some cases small-scale tests in real-world contexts before fully \ncommitting to a specific design. Although this works quite well in many \ncircumstances, it remains the case that measuring in real-world \ndeployments provides much higher validity than mathematical models and \nlab tests. As I\u2019ve shared in earlier posts, research by us and others \nshows that at least half of all the functions in a typical system are \nnever used or used so seldomly that the R&D investment is a waste. \nSo, wherever we can use techniques to deploy slices of functionality or \nfeatures and measure the effect before building more, we should as it \nallows for a major improvement in the effectiveness of our R&D.<\/p>\n\n\n\n

Although many understand that real-world experimentation concerning \nusability and user behavior is a necessity, the same is true for all \nquality attributes. Think of all the security fixes that we need to roll\n out. Often these concern vulnerabilities to threats that were known \nbefore the design of the system was finished. It just turned out that \nthe mitigation strategies that engineers designed into the system didn\u2019t\n suffice. Similarly, do we know for a fact that the current system \ndesign gives us the highest performance, the best robustness, the \nhighest energy efficiency? Of course not! Rather than relying on models \nand lab tests, we need real-world experiments with our products at \ncustomers in the field to continuously improve. The models and lab tests\n are still needed, but mostly to protect us from the downside of less \nsuccessful experiments before deployment.<\/p>\n\n\n\n

Concluding, if you\u2019re able to perfectly predict the optimal set of requirements for a system or product years ahead of the start of production or deployment and if you\u2019re able to accurately predict the effect of each requirement on the user, the customer and the quality attributes of the system, then you don\u2019t need Agile. In all other cases, Agile (both pre-deployment and post-deployment \u2013 DevOps) offers the opportunity for a massive improvement in the effectiveness of your R&D (as measured in value created for each unit of R&D). It\u2019s not that we can\u2019t build products using traditional waterfall processes \u2013 of course we can as we\u2019ve done so for decades. The challenge is that we\u2019re much less efficient doing so, which increases the risk of disruption for our company.<\/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":"

Recently, I got an e-mail asking me why we should care about Agile if the overall product development process, including mechanics and electronics, is measured in years and is completely waterfall. The question took me by surprise. I\u2019ve been working with Agile practices for the better part of two decades now and for me, it\u2019s … 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,3,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1066"}],"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=1066"}],"version-history":[{"count":2,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1066\/revisions"}],"predecessor-version":[{"id":1069,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1066\/revisions\/1069"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1066"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1066"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1066"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}