{"id":1822,"date":"2024-04-08T07:51:17","date_gmt":"2024-04-08T07:51:17","guid":{"rendered":"https:\/\/janbosch.com\/blog\/?p=1822"},"modified":"2024-04-08T07:51:18","modified_gmt":"2024-04-08T07:51:18","slug":"from-agile-to-radical-why","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2024\/04\/08\/from-agile-to-radical-why\/","title":{"rendered":"From Agile to Radical: why?"},"content":{"rendered":"\n
\"\"
Photo by Eden Constantino on Unsplash\n<\/figcaption><\/figure>\n\n\n\n

In recent months, I\u2019ve started a series of online and in-person workshops around Agile. These workshops have focused on the challenges of Agile, the things in Agile we want to keep, the things we want to remove as well as practices that we seek to add. Here, I intend to discuss the key elements of what I believe will be the next paradigm after Agile. However, before we dive into that, I think it behooves us to discuss why this is even a topic in the first place.<\/p>\n\n\n\n

The starting point for me was that during 2023, I started to notice that most of the companies I work with claim that they employ agile practices to some extent, but that in practice, these practices seldom went beyond the team level. There are several places where a set of teams operate using agile practices together and have set up a continuous integration and test infrastructure, but at the product, portfolio and company level, nothing has really changed for decades.<\/p>\n\n\n\n

Interestingly, many of these companies have adopted SAFe as the overall product development method for software. However, to quote a manager at one of the Software Center partners: \u201cWe adopted Agile and nothing changed.\u201d In most SAFe deployments I\u2019ve seen, it very much was an \u2018emperor\u2019s new clothes\u2019 situation: lots of smoke and mirrors but no fundamental changes to the business model, product development and other aspects of the business.<\/p>\n\n\n\n

Although there always have been Agile detractors, the majority of people I worked with at these companies, as well as I myself, have for the longest time felt that Agile was the right way forward and that the reason why we haven\u2019t come all the way with it is that we haven\u2019t tried hard enough and key decision makers didn\u2019t understand it. Last summer, I even wrote a blog post on the topic<\/a>.<\/p>\n\n\n\n

Over the last year, however, I\u2019ve started to entertain an alternative view: Agile simply is not, or is no longer, the right paradigm for product development, especially in the software-intensive industry. My current hypothesis is that no matter how hard we try to squeeze the square peg into the round hole, it simply isn\u2019t going to fit.<\/p>\n\n\n\n

To explore this, we need to go to the basis of Agile. To me, that\u2019s the Agile Manifesto. We\u2019ve all seen it, but it\u2019s important to remember that it was developed by people who, by and large, worked with a single team for an individual customer that the team had continuous access to.<\/p>\n\n\n\n

This is far from the reality for most engineers and teams. We\u2019re developing a product for a market consisting of hundreds, if not millions, of customers. We\u2019re in an organization with dozens of teams, all contributing to the product. The product contains mechanical, electronic and software parts. Finally, in many markets, customers are actively resisting continuous monetization and simply want to purchase the product, use it up and buy the next one, meaning that there\u2019s no business model to compensate for the costs associated with DevOps.<\/p>\n\n\n\n

The mismatch between the original principles and the reality of product development is where, in my view, things started to go off the rails. We needed to compensate and develop solutions for all the aspects that Agile didn\u2019t solve and where it ran into conflicts. Two easy ones are scale and atoms.<\/p>\n\n\n\n

When scaling development organizations, sprint planning with all teams is simply a nightmare. Hence, approaches like Agile focus on quarterly increment planning rather than bi-weekly. That of course is quite close to the waterfall-style \u2018iterative development\u2019 approaches that preceded Agile and far from a DevOps style of development.<\/p>\n\n\n\n

For products that include atoms, ie mechanics and electronics, we simply have to align with the fact that parts need to be ordered, manufacturing lines need to be planned and set up and that, gasp, we actually need to agree on a date far into the future when everything needs to be ready to avoid inefficiencies. No matter how agile you are, no company is going to set up a manufacturing line in a sprint or continuously evolve the mechanical and electronic parts of the product in response to new features and functionality.<\/p>\n\n\n\n

When stepping back and reflecting on the state of practice, my perspective is that many \u2018agile\u2019 approaches simply took pre-Agile, waterfall-style techniques to complement Agile where it fell short. This has resulted in the situation where we\u2019ve developed new labels and rituals but in practice, nothing has fundamentally changed.<\/p>\n\n\n\n

There\u2019s a group of people, often consultants, who claim that everything we can think of falls under the banner of Agile as, in their view, Agile is continuously evolving into something new. Of course, we can bolt on all kinds of practices, but at the core, there\u2019s a set of Agile principles underlying the entire paradigm that simply are there. Of course, we can call whatever we want \u201cagile,\u201d but it doesn\u2019t mean that we\u2019re still beholden to the paradigm as it was initially intended.<\/p>\n\n\n\n

Based on the workshops, several aspects of Agile can be identified that simply don\u2019t work or where we\u2019ve gone overboard. Take the many rituals and time-consuming practices that add little or no value. Another problem is that large efforts that are difficult to plan and implement can\u2019t be completed by one team in one sprint. Aligning agile software with lean and waterfall-oriented mechanics and electronics is difficult as well. When the number of teams becomes large, high coordination costs are incurred. When teams don\u2019t want to commit beyond a single sprint, product releases are impossible to plan. These are just a few of the many, many more concerns workshop participants had, next to the many responses they gave on how they solved some of the challenges while staying within the Agile paradigm.<\/p>\n\n\n\n

For the sake of argument, I\u2019m staking out my position: Agile has been great for the software development community. It was defined in the early 2000s as a reaction to the CMMI straightjacket that many older engineers may remember and it served that purpose well. In most contexts, developers have much more freedom than what a CMM level 5 organization would have afforded them. However, we\u2019ve reached the end of the Agile paradigm and we need to move on to something else. This \u201csomething else\u201d will maintain many of the elements of Agile, in the same way as Agile maintained elements from the waterfall paradigm before it. However, we need to take a fresh start in how we think about product development, unencumbered by what Agile has to offer. That\u2019s what this series will be about.<\/p>\n\n\n\n

The Agile paradigm was defined in 2001 in response to the strict process orientation of CMM. It has served us well for more than two decades, but the limitations of the paradigm are becoming increasingly visible for those who dare to look closely. We need to move on to a new paradigm that will address some of the key limitations of the Agile paradigm while maintaining several of the key principles. This requires a fresh start, rather than an evolution. To quote Christopher Ferry: \u201cA fresh start isn\u2019t a new place. It\u2019s a new mindset.\u201d<\/p>\n\n\n\n

Want to read more like this? Sign up for my newsletter at\u00a0jan@janbosch.com<\/a>\u00a0or follow me on\u00a0janbosch.com\/blog<\/a>, LinkedIn (linkedin.com\/in\/janbosch<\/a>)\u00a0or Twitter (@JanBosch<\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

In recent months, I\u2019ve started a series of online and in-person workshops around Agile. These workshops have focused on the challenges of Agile, the things in Agile we want to keep, the things we want to remove as well as practices that we seek to add. Here, I intend to discuss the key elements of … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","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\/1822"}],"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=1822"}],"version-history":[{"count":2,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1822\/revisions"}],"predecessor-version":[{"id":1825,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1822\/revisions\/1825"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1822"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1822"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1822"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}