{"id":3231,"date":"2021-12-02T16:17:03","date_gmt":"2021-12-02T16:17:03","guid":{"rendered":"https:\/\/agilebeyondboundary.com\/?p=3231"},"modified":"2021-12-02T16:17:03","modified_gmt":"2021-12-02T16:17:03","slug":"simplifying-agile-principles","status":"publish","type":"post","link":"https:\/\/agilebeyondboundary.com\/index.php\/2021\/12\/02\/simplifying-agile-principles\/","title":{"rendered":"Simplifying Agile Principles"},"content":{"rendered":"\n<ol class=\"wp-block-list\" type=\"1\"><li>Scrum and Agile practices, once the sole domain of software developers, are making significant inroads outside of IT and finding acceptance in industries beyond technology. &nbsp;2016 State of scrum report&nbsp;emphasized this.&nbsp;<\/li><\/ol>\n\n\n\n<ul class=\"wp-block-list\"><li>The agile mindset was recognized in 2001 at a summit of practitioners who found consensus around core values captured in 12 principles called the \u201cAgile Manifesto.&nbsp;&nbsp;<\/li><\/ul>\n\n\n\n<p>If you closely look at these two statements, there is a problem.&nbsp;&nbsp;&nbsp;<\/p>\n\n\n\n<p>The Agile principles&nbsp;were&nbsp;thought and build around software development by software practitioners.&nbsp; Obviously, the phrases of principles have much software or IT specific terminologies such as early and continuous delivery of valuable software OR emergent architecture &amp; technical design OR working software as principle measure of progress, so on and so forth. &nbsp;People from non IT \/ non technology industry may find it difficult to co-relate the principles directly&nbsp;to&nbsp;their work.&nbsp; &nbsp;<\/p>\n\n\n\n<p>We&nbsp;need more generic phrases applicable across industries,&nbsp;by simplifying the principles without losing its core essence.&nbsp;The face is&nbsp;many agile coaches and gurus have already done so;&nbsp; This blog is collection &amp; compilation of simplified \/ rephrased principles, that may help Agile enthusiastic from both IT and non-IT Industry.<\/p>\n\n\n\n<p><em><strong>Principle 1 &#8211;\u00a0\u00a0 Our highest priority is to satisfy customer through early and continuous delivery of valuable software\u00a0<\/strong><\/em><\/p>\n\n\n\n<p>Pay attention on \u2018customer satisfaction\u2019, you may ignore \u2018delivery of valuable software\u2019 part, rather think of something relevant to you \/ your industry.&nbsp; In reality, it doesn\u2019t matter what the deliverable is (software or some mechanical product or something else);&nbsp;what matters is customer satisfaction, which comes only upon return on investment. So, 1st principle of Agile is \u201c<strong>Customer ROI<\/strong>\u201d.<\/p>\n\n\n\n<p><em>*Here \u2018you\u2019 is referring to someone from non-IT industry&nbsp;<\/em><\/p>\n\n\n\n<p><em><strong>Principle 2 &#8211;\u00a0\u00a0\u00a0Welcome changing requirements, even in late development<\/strong><\/em><\/p>\n\n\n\n<p>How you can make yourself (you, your team, your process or your solution) welcoming to changes in requirement?&nbsp;&nbsp;<\/p>\n\n\n\n<p>By&nbsp;&nbsp;keeping your solution \/ process \/ tool \/ service \/ design changeable.&nbsp;&nbsp; Yes, 2<sup>nd<\/sup>&nbsp;Agile principle is&nbsp;\u201c<strong>Changeable<\/strong>\u201d&nbsp;<\/p>\n\n\n\n<p><em><strong>Principle 3 &#8211;\u00a0\u00a0 Working software is delivered frequently (weeks rather than months)<\/strong><\/em><\/p>\n\n\n\n<p>Again, you may ignore&nbsp;\u2018working software\u2019&nbsp;part and pay attention on&nbsp;\u2018delivered frequently\u2019.&nbsp; It\u2019s all about&nbsp;\u2018<strong>Getting&nbsp;Real\u201d<\/strong>as close as real time response to customer need.<\/p>\n\n\n\n<p><em><strong>Principle 4 &#8211;\u00a0\u00a0 Close, daily cooperation between business people and developers<\/strong><\/em><\/p>\n\n\n\n<p>Daily standup is most popular and arguably most effective way to achieve it.&nbsp; Your business context may not allow you to do so. Read again this principle and think what it wants to achieve. Yes, it\u2019s all about \u201c<strong>Clarity\u201d.&nbsp;&nbsp;<\/strong>4<sup>th<\/sup>&nbsp;Principle is&nbsp;to&nbsp;bring more clarity to everyone and everything. You may design your own way to achieve it.<\/p>\n\n\n\n<p><em><strong>Principle 5 &#8211;\u00a0\u00a0 Projects are built around motivated individuals, give them environment and support their needs, and trust them to get the job done<\/strong><\/em><\/p>\n\n\n\n<p>It is already generic.&nbsp; \u201c<strong>Self organizing team\u201d<\/strong>&nbsp;is the 5<sup>th<\/sup>&nbsp;principle of agile.<\/p>\n\n\n\n<p><em><strong>Principle 6 \u2013\u00a0\u00a0\u00a0Face-to-face conversation is the best form of communication (co-location)<\/strong><\/em><\/p>\n\n\n\n<p>Co-location may not work well for every industry. What can work well is investment on tools and bandwidth to create&nbsp;<strong>virtually co-located<\/strong>&nbsp;teams \/ workspace.&nbsp;&nbsp;Invest in bandwidth.&nbsp;<\/p>\n\n\n\n<p><em><strong>Principle 7 \u2013\u00a0\u00a0\u00a0Working software is the principal measure of progress<\/strong><\/em><\/p>\n\n\n\n<p>In non-IT you don\u2019t have working software, so what can be your principle measure of success ?&nbsp;&nbsp;&nbsp;<\/p>\n\n\n\n<p>Pay attention on the first and last part viz \u2018Working\u2019 and \u2018measure of success\u2019.&nbsp;&nbsp; Here it means \u201c<strong>Boolean done<\/strong>\u201d &#8211; either something is done(working) or not done, Measure of success cannot be on something work in progress or partial completion; nothing like 40 % complete or 80 % &nbsp;complete.&nbsp;<\/p>\n\n\n\n<p>This is really interesting and important.&nbsp; &nbsp;None of your matrices \/ MIS should be on partial or % completion.&nbsp;&nbsp;&nbsp;&nbsp;<\/p>\n\n\n\n<p>Design your matrices with Boolean done approach to embrace 7<sup>th<\/sup>&nbsp;principle.&nbsp;<\/p>\n\n\n\n<p><em><strong>Principle 8 &#8211;\u00a0\u00a0\u00a0Sustainable development, able to maintain a constant pace<\/strong><\/em><\/p>\n\n\n\n<p>People are not resource, they are people.&nbsp;&nbsp; If your team \/ people are working extra time, they will burn out soon; if they are working too less, they will bored soon.&nbsp; Need to have a balance; understand people\u2019s need and accordingly frame your working rules and&nbsp;process.&nbsp; 8<sup>th<\/sup>&nbsp;principle is about \u201c<strong>sustainability\u201d<\/strong>, and it comes from treating people as human and not as resource.&nbsp;&nbsp;<\/p>\n\n\n\n<p>[By the way who invented the term \u2013 \u201chuman resource\u201d?&nbsp; I hate him\/her in my subconscious mind]<\/p>\n\n\n\n<p><em><strong>Principle 9 \u2013\u00a0\u00a0\u00a0Continuous attention to technical excellence and good design<\/strong><\/em><\/p>\n\n\n\n<p>Pay attention on&nbsp;\u2018continuous attention\u2019&nbsp;and ignore the&nbsp;\u2018technical excellence or&nbsp;design\u2019&nbsp;part,&nbsp;if&nbsp;it is not applicable to your industry.&nbsp; But, don\u2019t misunderstood continuous attention with micro management or continuous follow up.&nbsp;&nbsp;&nbsp;9<sup>th<\/sup>principle is about review and<strong>&nbsp;\u201cContinuous Collaboration\u201d.<\/strong><\/p>\n\n\n\n<p><em><strong>Principle 10 \u2013\u00a0\u00a0\u00a0\u00a0Simplicity\u2014the art of maximizing the amount of work not done\u2014is essential<\/strong><\/em><\/p>\n\n\n\n<p>Nobel prize winner poet Rabindranath Tagore said- &nbsp;&#8216;It is very simple&nbsp;to be happy,&nbsp;but&nbsp;it is very&nbsp;difficult to be simple.&#8217;&nbsp; 10<sup>th<\/sup>&nbsp;principle is in&nbsp;the&nbsp;same lines, how to make things simple. &nbsp;&nbsp;<\/p>\n\n\n\n<p>Be it process, rules, tools, reporting, &nbsp;governance or operating model or your code &amp; architecture (sorry, I&nbsp;broughtsome IT stuff here).&nbsp;&nbsp; Often people make things complicated, either out of nature or out of making something too perfect or out of over thinking.&nbsp;<\/p>\n\n\n\n<p>Agile is all about \u201c<strong>Simplicity\u201d.<\/strong><\/p>\n\n\n\n<p><em><strong>Principle 11 \u2013 Best architectures, requirements, and designs emerge from self-organizing teams<\/strong><\/em><\/p>\n\n\n\n<p>You may comfortably ignore \u2018architecture and design\u2019 etc, and pay attention on \u2018emerge from self-organizing team\u2019.&nbsp; If you abide to 5th principle (self organizing team), all you need is to have patience and belief; things will \u201c<strong>Evolve<\/strong>\u201d and take best shape itself.&nbsp;&nbsp;<\/p>\n\n\n\n<p><em><strong>Principle 12 \u2013 Regularly, the team reflects on how to become more effective, and adjusts accordingly<\/strong><\/em><\/p>\n\n\n\n<p>No point for guessing this. It\u2019s \u201c<strong>Inspect and adopt<\/strong>,&nbsp;<strong>frequently\u201d<\/strong>.&nbsp;&nbsp; Again frequency should be sustainable, neither too frequent nor too less.&nbsp;<\/p>\n\n\n\n<p><strong>Summary Chart&nbsp;&#8211;<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>Principle<\/strong><\/td><td><strong>Core essence<\/strong><\/td><\/tr><tr><td>1<\/td><td>ROI (return of investment)<\/td><\/tr><tr><td>2<\/td><td>Changeable<\/td><\/tr><tr><td>3<\/td><td>Getting Real&nbsp; \/ Real \u2013 time<\/td><\/tr><tr><td>4<\/td><td>Clarity<\/td><\/tr><tr><td>5<\/td><td>Self organizing team<\/td><\/tr><tr><td>6<\/td><td>(Virtually) co-located&nbsp;<\/td><\/tr><tr><td>7<\/td><td>Boolean done<\/td><\/tr><tr><td>8<\/td><td>Sustainable pace<\/td><\/tr><tr><td>9<\/td><td>Continuous collaboration \/ review<\/td><\/tr><tr><td>10<\/td><td>Simplicity&nbsp;<\/td><\/tr><tr><td>11<\/td><td>Evolve<\/td><\/tr><tr><td>12<\/td><td>Inspect and Adopt, frequently &nbsp;<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>As mentioned above, this post is more of a compilation or collection of the thoughts presented by many agile coaches and gurus time to time, and some original thoughts&nbsp;may have been unintentionally overridden by other.&nbsp; Apology for any such case.&nbsp;&nbsp;<\/p>\n\n\n\n<p>My sincere regards and thanks to Dr. Andreas Wintersteiger, his training and session inspired me to start looking at agile principles in more generic and simpler way.<\/p>\n\n\n\n<p>The blog was originally published in Scrum Alliance, republishing here with due permission&nbsp;<\/p>\n\n\n\n<figure class=\"wp-block-embed\"><div class=\"wp-block-embed__wrapper\">\nhttps:\/\/www.scrumalliance.org\/community\/articles\/2017\/july\/agile-principles-from-a-non-it-industry-standpoint\n<\/div><\/figure>\n","protected":false},"excerpt":{"rendered":"<p>Scrum and Agile practices, once the sole domain of software developers, are making significant inroads outside of IT and finding acceptance in industries beyond technology. &nbsp;2016 State of scrum report&nbsp;emphasized this.&nbsp; The agile mindset was recognized in 2001 at a summit of practitioners who found consensus around core values captured in 12 principles called the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3232,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_oct_exclude_from_cache":false,"footnotes":""},"categories":[15,14,9],"tags":[17,19,36,37,16,22,21,25,18,20],"class_list":["post-3231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agilework","category-leadership","category-people","tag-agile","tag-agile-coaching","tag-agile-mindset","tag-agile-principles","tag-antipatterns","tag-banking","tag-best-practices","tag-distributed-agile","tag-leadership","tag-mentoring"],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":6}},"_links":{"self":[{"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/posts\/3231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/comments?post=3231"}],"version-history":[{"count":1,"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/posts\/3231\/revisions"}],"predecessor-version":[{"id":3233,"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/posts\/3231\/revisions\/3233"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/media\/3232"}],"wp:attachment":[{"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/media?parent=3231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/categories?post=3231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilebeyondboundary.com\/index.php\/wp-json\/wp\/v2\/tags?post=3231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}