But is<\/em> it? Not everything<\/em>, certainly.<\/p>\n\n\n\n The manifesto, in its day, was written by a bunch of software development consultants. “Development<\/strong>” being a key term here.<\/p>\n\n\n\n “Operations” was so much of a different organizational silo then, that it took another eight years1<\/a><\/sup> before the term “DevOps2<\/a><\/sup>” was coined. So…<\/p>\n\n\n\n Also not. Attentive readers of the Manifesto will be aware that even in 2001 there wasn’t a clear line keeping “software developers” in and others out. Quite the opposite. “Business people and developers must work\u00a0together daily throughout the project<\/em>“, they said, and “sponsors, developers, and users<\/em>” and “architectures, requirements, and designs\u00a0emerge from self-organizing teams<\/em>“3<\/a><\/sup>. So if the criterion is neither the domain (“software”) nor the function (“programmers”) – how do<\/em> you decide where to apply “Agile”?<\/p>\n\n\n\n …or rather: complex<\/strong>, chaotic<\/strong> or disorder<\/strong>ly. Using the Cynefin<\/strong>4<\/a><\/sup>-framework, we would cast our net at any problem domain outside of “clear<\/strong>“. Whenever there isn’t a simple, “best practice” approach to what we intend to accomplish, whenever the “unknown” sneaks up on the “known” with some regularity5<\/a><\/sup>, we’re better off being ready to adapt rather than “following a plan”6<\/a><\/sup>.<\/p>\n\n\n\n … what is “unknown”? That one is actually easy: “f*** around and find out<\/em>“, they say. And there really is way around. Or, if salty language isn’t your thing, let’s call it “the scientific method<\/strong>7<\/a><\/sup>“:<\/p>\n\n\n\n …and where to draw the line? The answer to that one is slightly more uncomfortable and yet another question: “how much can you afford to lose<\/em>?”. I’d suggest to take inspiration from the Agile Manifesto already and limit yourself to “working” <\/em>[software]8<\/a><\/sup> as the minimum and “a\u00a0couple of weeks […], with a\u00a0preference to the shorter timescale<\/em>” as the maximum.<\/p>\n\n\n\n Within this shortest possible timespan from hypothesis to proof, feel free to “waterfall9<\/a><\/sup>” the following to your heart10<\/a><\/sup>‘s content:<\/p>\n\n\n\n If so, feel free to increase your bet to a more ambitious definition of “working”. Feel free, eventually, to increase your bet to a longer timespan. … “classical project management” and “Waterfall12<\/a><\/sup>” are not sufficient and most likely will not be so in the future.<\/p>\n\n\n\n “If only we can be a 100% right in our Planning<\/em>,” the thinking went, “then we will reap never-ending economies of scale in our Doing<\/em>” … ignoring the mathematical truth, if inconvenience, that the time needed to “Do” something will never quite converge towards zero, while the multiplied probability of getting the “Plan” right for lots of different things certainly does.<\/p>\n\n\n\n So if “Planning” really only works for very simple things and “Project Management” can’t compensate for more than the very simplest of planning errors,<\/p>\n\n\n\n Follow me here for more…<\/p>\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" … everything looks like a nail But is it? Not everything, certainly. The manifesto, in its day, was written by a bunch of software development consultants. “Development” being a key term here. “Operations” was so much of a different organizational silo then, that it took another eight years before the term “DevOps” was coined. So… … <\/p>\n Continue reading “If all you have is a hammer…”<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"[{\"content\":\"2009 - https:\/\/en.wikipedia.org\/wiki\/DevOps<\/a>\",\"id\":\"40b50d4a-617b-439a-aecb-942b20c1737b\"},{\"content\":\"if you want to read up, a better starting point might be https:\/\/www.goodreads.com\/book\/show\/8686650-continuous-delivery<\/a>\",\"id\":\"352f0b45-0f65-4baf-8350-3cbb560c92c7\"},{\"content\":\"principles 4, 8 and 11, respectively: http:\/\/agilemanifesto.org\/principles.html<\/a>\",\"id\":\"479d7c90-bdd4-42f8-bbd7-0d5565d3a55c\"},{\"content\":\"https:\/\/en.wikipedia.org\/wiki\/Cynefin_framework<\/a>\",\"id\":\"2046389c-4c18-4d48-b829-0d5c6b846ab7\"},{\"content\":\"if not predictability - easily confused topics, for sure, but quite different in how they should be treated\",\"id\":\"5e7e9c02-fff4-492b-be92-0389e76abcb6\"},{\"content\":\"\\\"Responding to change\u00a0over following a plan<\/em>\\\" is what gave \\\"Agile\\\" it's name, after all\",\"id\":\"44ab893c-0ef3-4aec-bc07-3dc72c41907d\"},{\"content\":\"https:\/\/en.wikipedia.org\/wiki\/Empiricism<\/a> or https:\/\/en.wikipedia.org\/wiki\/Scientific_method<\/a> respectively\",\"id\":\"b96a7607-ee5a-4343-9c43-9c2b02ee9572\"},{\"content\":\"feel free to drop \\\"software\\\" and enter any problem domain of your own choosing\",\"id\":\"1908e05f-4383-43bf-a87b-2275f05e5017\"},{\"content\":\"https:\/\/en.wikipedia.org\/wiki\/Waterfall_model<\/a>\",\"id\":\"513ff7db-0b86-444d-8191-57a6750de45d\"},{\"content\":\"intuitively, I will admit, \\\"Waterfall\\\" just feels<\/em> right. \\\"Plan perfectly<\/em>\\\", then \\\"do not deviate from this perfection<\/em>\\\" even has some logic to it. If only perfection were a thing...\",\"id\":\"4fbb14b4-b59f-4792-b9fc-f6217a57cfc7\"},{\"content\":\"https:\/\/strategicmanagementinsight.com\/tools\/pdca-plan-do-check-act\/<\/a> ... the \\\"Waterfall\\\" before someone tried saddling it with \\\"economies of scale\\\" https:\/\/en.wikipedia.org\/wiki\/Economies_of_scale<\/a> and forgot all about \\\"lot size one\\\" https:\/\/www.allaboutlean.com\/one-piece-flow\/<\/a>\",\"id\":\"2c0dd4a6-e02c-4d90-a8b4-131d38cec0f7\"},{\"content\":\"...which even Winston Royce, who is credited for writing \\\"the paper\\\" on it called \\\"risky and [inviting] failure<\/em>\\\". For whatever reason, the paper is rarely read and historically misunderstood in that Mr. Royce actually tried to warn against<\/em> adopting such an approach\",\"id\":\"5b8cd8c1-8e34-48be-8726-7d0f0dc8791e\"}]"},"categories":[1],"tags":[],"class_list":["post-71","post","type-post","status-publish","format-standard","hentry","category-allgemein","entry"],"_links":{"self":[{"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=\/wp\/v2\/posts\/71","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=71"}],"version-history":[{"count":1,"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=\/wp\/v2\/posts\/71\/revisions"}],"predecessor-version":[{"id":74,"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=\/wp\/v2\/posts\/71\/revisions\/74"}],"wp:attachment":[{"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=71"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=71"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/theagilistcookbook.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=71"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}“Software”, you say?<\/h3>\n\n\n\n
It’s complicated<\/h3>\n\n\n\n
But how can we know<\/h3>\n\n\n\n
\n
Experiments and Waterfalls<\/h3>\n\n\n\n
\n
Did you get what you wanted?<\/h3>\n\n\n\n
Feel free, eventually, to say that “Agility” isn’t what you need, because the problem domain is obviously “complicated” at most and how you’re solving it is “good practice” at least, maybe even “best practice”, because it is “clear”.<\/p>\n\n\n\nIn any other case<\/h3>\n\n\n\n
…what better tools do we have?<\/h3>\n\n\n\n