{"id":6392,"date":"2014-01-02T12:57:04","date_gmt":"2014-01-02T12:57:04","guid":{"rendered":"https:\/\/www.bridge-global.com\/blog\/blog\/\/?p=6392"},"modified":"2020-09-21T09:55:31","modified_gmt":"2020-09-21T09:55:31","slug":"golden-rules-for-agile-process-improvement","status":"publish","type":"post","link":"https:\/\/www.bridge-global.com\/blog\/golden-rules-for-agile-process-improvement\/","title":{"rendered":"<!--:en-->Golden Rules for Agile Process Improvement<!--:-->"},"content":{"rendered":"<p><img loading=\"lazy\" decoding=\"async\" class=\"float-left alignleft wp-image-6393 size-thumbnail\" title=\"gold-bars\" src=\"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2014\/01\/gold-bars-150x150.jpg\" alt=\"\" width=\"150\" height=\"150\">I\u2019ve worked in a multi-site Process Improvement Team that adopted an&nbsp;<a href=\"http:\/\/www.benlinders.com\/2010\/process-improvement-the-agile-way\/\" target=\"_blank\" rel=\"noopener\">Agile way of working<\/a>.The team used a set of \u201cGolden Rules\u201d. These rules helped them to understand the agile approach, and to work together in a smooth, efficient and positive way. These golden rules were formulated based upon principles from the&nbsp;<a href=\"http:\/\/agilemanifesto.org\/\" target=\"_blank\" rel=\"noopener\">Agile Manifesto<\/a>,&nbsp;EVO,&nbsp;<a href=\"http:\/\/www.openspaceworld.org\/\" target=\"_blank\" rel=\"noopener\">Open Space Technology<\/a>,&nbsp;<a href=\"http:\/\/www.solworld.org\/\" target=\"_blank\" rel=\"noopener noreferrer\">Solution Focused<\/a>,&nbsp;<a title=\"Getting to the Root Cause of problems\" href=\"http:\/\/www.benlinders.com\/2010\/getting-to-the-root-cause-of-problems\/\" target=\"_blank\" rel=\"noopener\">Root Cause Analysis<\/a>, and&nbsp;Retrospectives.<\/p>\n<p>The rules that we have used are:<\/p>\n<ul>\n<li>Dare to share \u2013 As early as possible and frequently<\/li>\n<li>The result depends on the team \u2013 Not the individual members<\/li>\n<li>The one who checks out a task is not necessarily the one who has to finish it<\/li>\n<li>The one\u2019s working on a task are the right people<\/li>\n<li>You may critique anything, but you may never criticize anyone<\/li>\n<\/ul>\n<p>This simple set of rules was used throughout the project as a guideline on how we collaborated, they were our team values. They helped the team members to learn and adapt the agile approach, in a very practical way.<\/p>\n<p><strong>Dare to share \u2013 As early as possible and frequently<\/strong><\/p>\n<p>Team members often worked in short chunks of just a couple of hours, whenever time was available in their personal schedules (In Dutch, we applied Het Nieuwe Werken). They produced and updated slides and documents, web pages, news items, or other content. Work items were frequently reviewed, the feedback was visible for all team members. By sharing early we were able to continuously add value to our products, enabling delivery in short iterations.<\/p>\n<p>This origins back to Agile and EVO, iteratively deliver value for your customer. You can use a a wiki as working space (as we did with our team), or a cloud solution like&nbsp;<a href=\"https:\/\/sites.google.com\/\" target=\"_blank\" rel=\"noopener noreferrer\">Google Sites<\/a>, or&nbsp;<a href=\"http:\/\/www.huddle.com\/\" target=\"_blank\" rel=\"noopener noreferrer\">Huddle<\/a>. Recently I\u2019ve started evaluating and using&nbsp;Worknets as a collaboration environment,&nbsp;for the team of&nbsp;<a href=\"http:\/\/www.veranderproject.nl\/\" target=\"_blank\" rel=\"noopener noreferrer\">veranderproject.nl<\/a>.<\/p>\n<p><strong>The result depends on the team \u2013 Not the individual members<\/strong><\/p>\n<p>Team members frequently asked other team members to support them, or to contribute their experience or results from their own R&amp;D centre to the project. This rule helped the team members reminding that we all brought value to the team, at different times and in different ways, using our individual strengths. Since we were all also representing our local R&amp;D centre, this was an important value which helped the team, and the stakeholders to focus upon the contribution to the business unit result, and be open for experiences from other R&amp;D centers. We weren\u2019t competitors but co-workers, and the way we collaborated was beneficial for all involved, and for the company as a whole.<\/p>\n<p>This rule focuses on using strengths, as described in techniques like&nbsp;<a href=\"http:\/\/www.presencing.com\/presencing\" target=\"_blank\" rel=\"noopener noreferrer\">Theory U<\/a>,&nbsp;<a href=\"http:\/\/www.benlinders.com\/2011\/devil%E2%80%99s-or-angel%E2%80%99s-advocate-which-role-do-you-prefer\/\" target=\"_blank\" rel=\"noopener noreferrer\">Angels Advocate<\/a>,&nbsp;<a href=\"http:\/\/liveingreatness.com\/core-protocols\/perfection-game\/\" target=\"_blank\" rel=\"noopener noreferrer\">Perfection Game<\/a>,&nbsp;<a href=\"http:\/\/appreciativeinquiry.case.edu\/\" target=\"_blank\" rel=\"noopener noreferrer\">Appreciative Inquiry<\/a>&nbsp;and&nbsp;<a href=\"http:\/\/www.solworld.org\/\" target=\"_blank\" rel=\"noopener noreferrer\">Solution Focused<\/a>. (I recently wrote an article in Dutch on this subject:&nbsp;<a title=\"Veranderen vanuit je Sterktes: Da&#039;s Anders!\" href=\"http:\/\/www.benlinders.com\/2011\/veranderen-vanuit-je-sterktes-das-anders\/\" target=\"_blank\" rel=\"noopener\">Veranderen vanuit je Sterktes: Da\u2019s Anders!<\/a>).<\/p>\n<p><strong>The one who checks out a task is not necessarily the one who has to finish it<\/strong><\/p>\n<p>Team members supported each other, and collaborated where possible. It was ok for a team member to contribute just a little bit to a product, and release it for others to work on. If somebody wanted to contribute to a product that was being updated, then (s)he picked it up when it became available, and then added his\/her contribution. &nbsp;Since work items were checked-in quickly (often within minutes or an hours after check-out), this worked very smoothly.<\/p>\n<p>Also this rules is based upon using strengths, as described for instance by <a href=\"http:\/\/alistair.cockburn.us\/Solutions+Focus+aka+Delta+Method\" target=\"_blank\" rel=\"noopener noreferrer\">Alistair Cockburn in the Delta Method<\/a>&nbsp;(which is based upon&nbsp;<a href=\"http:\/\/www.solworld.org\/\" target=\"_blank\" rel=\"noopener noreferrer\">Solution Focused<\/a>). To be effective, team members have to trust each other, and assume that everybody is doing the best job they can; this principle uses the&nbsp;Retrospectives Prime Directive.<\/p>\n<p><strong>The one\u2019s working on a task are the right people:<\/strong><\/p>\n<p>We saw that when team members had the time, and the energy to work on a certain task, then they added real value to the product or service that they were working on. Team members did not wait for others to pick up tasks, but contributed when they had the possibility to do it. The team members felt empowered to contribute to the result of the process improvement project in ways that we did not expect when we started the project. Their experience and knowledge came forward, simply by giving them the means to contribute, and setting the right culture to do it.<\/p>\n<p>We learned this rule from&nbsp;<a href=\"http:\/\/www.openspaceworld.org\/\" target=\"_blank\" rel=\"noopener\">Open Space Technology<\/a>: \u201cWhoever comes is the right people\u201d. Team members that manage their contribution to the the result in an discplined way, they contribute what they have, when they can, in the best way that they can do it.<\/p>\n<p><strong>You may critique anything, but you may never criticize anyone<\/strong><\/p>\n<p>This reminded the team to always focus on the products and services that were developed. Often it was just a matter of wording, how team members expressed their critique, but that didn\u2019t make it less important to be aware how they did it. We always assumed that people were doing the best they could, based upon what they knew and were able to do at that point in time.<\/p>\n<p>Criticizing the work, and not the person is an important rule that I learnt doing reviews and inspections. It creates an atmosphere where people can give feedback, and where receivers will be open for feedback. It also helps to do&nbsp;<a href=\"http:\/\/www.benlinders.com\/2013\/whats-an-agile-retrospective-and-why-would-you-do-it\/\" target=\"_blank\" rel=\"noopener\">retrospectives<\/a>&nbsp;and&nbsp;<a title=\"Getting to the Root Cause of problems\" href=\"http:\/\/www.benlinders.com\/2010\/getting-to-the-root-cause-of-problems\/\" target=\"_blank\" rel=\"noopener\">find the Root Causes of problems<\/a>, and take actions to prevent similar problems from happening in the future. Assuming that people are doing the best job they can is again based upon the&nbsp;<a href=\"http:\/\/www.benlinders.com\/2011\/getting-business-value-out-of-agile-retrospectives\/\" target=\"_blank\" rel=\"noopener\">Retrospectives Prime Directive<\/a>.<\/p>\n<p><strong>Conclusions<\/strong><\/p>\n<p>These golden rules are something that my team members have learned in the project, and are still using in their current work. For them it is a way to collaborate effectively and efficiently in a team. Your rules will (and should) be different, depending on your needs and the situation at hand. But my expectation is that you can re-use from the principles that we have used to define our rules: The&nbsp;<a href=\"http:\/\/agilemanifesto.org\/\" target=\"_blank\" rel=\"noopener\">Agile Manifesto<\/a>,&nbsp; EVO,&nbsp;<a href=\"http:\/\/www.openspaceworld.org\/\" target=\"_blank\" rel=\"noopener\">Open Space Technology<\/a>,&nbsp;<a href=\"http:\/\/www.solworld.org\/\" target=\"_blank\" rel=\"noopener noreferrer\">Solution Focused<\/a>,&nbsp;and&nbsp;<a href=\"http:\/\/www.retrospectives.eu\/\" target=\"_blank\" rel=\"noopener noreferrer\">Retrospectives<\/a>.<\/p>\n<p>This article was originally published by <a href=\"http:\/\/www.benlinders.com\/\" target=\"_blank\" rel=\"noopener\">Ben Linders<\/a>&nbsp;in his blog post&nbsp;<a href=\"http:\/\/www.benlinders.com\/2011\/golden-rules-for-agile-process-improvement\/\" target=\"_blank\" rel=\"noopener\">Golden Rules for Agile Process Improvement<\/a>.<\/p>\n<p><a href=\"http:\/\/bridge-global.com\/ebooks\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-7877\" title=\"ebook2\" src=\"https:\/\/www.bridge-global.com\/blog\/\/wp-content\/uploads\/2014\/01\/ebook23.jpg\" alt=\"\" width=\"685\" height=\"322\" srcset=\"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2014\/01\/ebook23.jpg 685w, https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2014\/01\/ebook23-300x141.jpg 300w, https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2014\/01\/ebook23-500x235.jpg 500w\" sizes=\"auto, (max-width: 685px) 100vw, 685px\" \/><\/a><\/p>\n<p>&nbsp;<\/p>\n<p><!--:--><!--:nl--><\/p>\n<p><!--:--><!--:sv--><\/p>\n<p><!--:--><!--:de--><\/p>\n<p><!--:--><\/p>\n<!-- AddThis Advanced Settings generic via filter on the_content --><!-- AddThis Share Buttons generic via filter on the_content -->","protected":false},"excerpt":{"rendered":"<p><!--:en-->I\u2019ve worked in a multi-site Process Improvement Team that adopted an Agile way of working.The team used a set of \u201cGolden Rules\u201d. These rules helped them to understand the agile approach, and to work together in a smooth, efficient and positive way. These golden rules were formulated based upon principles from the Agile Manifesto, EVO, Open Space Technology, Solution Focused, Root Cause Analysis, and Retrospectives.<!--:--><!-- AddThis Advanced Settings generic via filter on get_the_excerpt --><!-- AddThis Share Buttons generic via filter on get_the_excerpt --><\/p>\n","protected":false},"author":54,"featured_media":45423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[44],"tags":[],"class_list":["post-6392","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile-outsourcing"],"featured_image_src":"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2014\/01\/Agile.jpg","author_info":{"display_name":"Ben Linders","author_link":"https:\/\/www.bridge-global.com\/blog\/author\/ben-linders\/"},"_links":{"self":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/6392","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/users\/54"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/comments?post=6392"}],"version-history":[{"count":9,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/6392\/revisions"}],"predecessor-version":[{"id":45424,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/6392\/revisions\/45424"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media\/45423"}],"wp:attachment":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media?parent=6392"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/categories?post=6392"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/tags?post=6392"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}