{"id":12081,"date":"2014-03-17T09:57:37","date_gmt":"2014-03-17T07:57:37","guid":{"rendered":"http:\/\/mozaicworks.com\/?p=6463"},"modified":"2014-03-17T09:57:37","modified_gmt":"2014-03-17T07:57:37","slug":"5-tips-to-avoid-release-hell-as-scrum-master","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/5-tips-to-avoid-release-hell-as-scrum-master","title":{"rendered":"5 Tips to Avoid Release Hell As Scrum Master"},"content":{"rendered":"

A Scrum Master friend of mine missed Karaoke night on Saturday because she had to stay until midnight at work getting the release out of the door. Briefly, the story is like this:<\/p>\n

It was the release week and the new version of the application should have been on UAT environment on Thursday night. Even if the team worked overtime every day, the release wasn\u2019t ready on Friday evening. Everyone had to come on Saturday because the release of other applications depended on it. The release was finally made on Saturday at midnight, with minor configurations left for Sunday and small bugs for Monday.<\/p><\/blockquote>\n

Does it sound familiar? I am sure many of you have experienced such a black weekend or night. Or both.<\/p>\n

When I heard this story, I had a question: what should a\u00a0Scrum Master<\/a>\u00a0do in this situation? Here are some options:<\/p>\n

Short term and immediate actions<\/h2>\n

1. Emergency retrospective<\/h3>\n

Even if Scrum requires a retrospective after each sprint, sometimes it\u2019s not enough. This situation triggers an emergency retrospective after the release with the purpose of understanding what has slowed down the release and define actions that will avoid similar issues. A focused meeting allows productive collaboration to find solutions and create the improvement actions.<\/p>\n

The Scrum Master role mandates that she will make sure the meeting has the best chances of success. Here are some hints for what she could do:<\/p>\n

    \n
  • Set a\u00a0simple structure for the meeting<\/strong>: state context, gather what went wrong from the team\u2019s members point of view, discuss what corrective actions to take<\/li>\n
  • Facilitate the meeting<\/strong>\u00a0according to this structure<\/li>\n
  • Avoid the blame game<\/strong>\u00a0through facilitation, by presenting the events in a neutral way.<\/li>\n
  • Help the team members\u00a0blow steam before the meeting<\/strong>\u00a0(as a suggestion, one on one coffee break discussions helps a lot). This comes from understanding of how teams work: it\u2019s rarely someone\u2019s fault for a mistake, usually the system set for the team is not set in a way to avoid those types of mistakes.<\/li>\n<\/ul>\n

    2. Change the team policies<\/h3>\n

    Any team respects a set of policies. Scrum teams in particular have things such as: Definition of Done, Definition of Ready, the sprint length, a choice of technical practices they use and so on. These policies should change to reflect what the team has learned from the incident. Here are 4 possible team policies\u2019 changes:<\/p>\n

      \n
    • Review the definition of done<\/strong>: A story shouldn\u2019t be marked as done if its deployment information is not clear and not validated by the deployment team. The Scrum Master involves the team in improving this definition. She makes it visible and enforces it to be followed.<\/li>\n
    • Review stories against the definition of done<\/strong>: The stories having impact on the deployment scripts are reviewed with the deployment team before marking them as ready for testing. The Scrum Master arranges for a colleague from Operations (Ops) to participate in these reviews.<\/li>\n
    • Update release scripts every week or when a story is ready for test<\/strong>: For a good release, this practice must be included in the definition of done. After making the definition visible and bringing Ops to collaborate, the Scrum Master checks on the good execution of this practice and takes corrective actions when needed.<\/li>\n
    • Release to test environment more often<\/strong>: To avoid unexpected situations when releasing to production, deploying often on test environment is a solution. If the test environment is a copy of the production environment, then the risk of having a broken release decreases considerably. The Scrum Master has the responsibility to present this idea to the team and get the support of technical leaders to run an experiment.<\/li>\n<\/ul>\n

      Actions for the long term<\/h2>\n

      For the deeper issues, we have to pay even more attention. Here are some long-term actions that can solve more problems at once:<\/p>\n

      3. More automated acceptance tests<\/h3>\n

      A broken release introduces regressions. Regressions should be caught early so that the team has enough time to fix them. One solution is to implement automated acceptance tests and schedule them to run every day on a test environment where last changes were deployed.<\/p>\n

      For teams that are not eager to try this practice, the Scrum Master can build a case for running an experiment: how about one person from the team (maybe even the Scrum Master) writes a few automated acceptance tests and presents them to the team at the next retrospective? There are two advantages in this case:<\/p>\n

        \n
      • It validates that automated acceptance tests are the right solution for this problem in the team\u2019s context<\/li>\n
      • It\u2019s easier to accept the change<\/li>\n
      • One person learns how to implement the automated acceptance tests and can teach the others at a later time<\/li>\n<\/ul>\n

        4. Automate builds<\/h3>\n

        There is an alternative to deploy often on test environment: automated builds. The developers and the Ops team can work together to implement this change. They should continue to collaborate in order to keep the scripts up to date. This long-term action can be a success if the Scrum Master has the skills to organize the collaboration between the two teams.<\/p>\n

        5. Better communication with the Operations (Ops) team<\/h3>\n

        Sometimes, the developers and the operations\u2019 teams have different types of tasks and most of the time they work separately. Organizing their collaboration can therefore present many challenges.<\/p>\n

        The Scrum Master can start with improving the communication between the two teams with:<\/p>\n

          \n
        • Raise the frequency of discussions with the Scrum Master or Team Leader from the Ops team. After a while the communication gets better and the two teams keep themselves up to date about the release-related issues<\/li>\n
        • A developer can team up with an Ops member and release to test environment whenever a story generates deployment changes.<\/li>\n<\/ul>\n

          Conclusion<\/h2>\n

          Release management is not easy, but the Scrum Master can have a positive impact upon it by using her skills to obtain the following benefits:<\/p>\n

            \n
          • increase the morale<\/strong>\u00a0of the team after a difficult moment<\/li>\n
          • help the team realize\u00a0the importance of the retrospective<\/strong><\/li>\n
          • improve communication<\/strong>\u00a0with the Ops team<\/li>\n
          • motivate the team to write\u00a0acceptance tests<\/strong><\/li>\n
          • enforce\u00a0best practices<\/strong>\u00a0inside the team: pair-programming, pair-testing, pair-review<\/li>\n
          • spot bad execution of release practices<\/strong>\u00a0earlier and take corrective actions right away<\/li>\n
          • lead the team to\u00a0collaborate with the Ops team<\/strong>\u00a0throughout the whole development cycle<\/li>\n<\/ul>\n

            After the next successful release, you can celebrate with your team during a karaoke night! Until then,\u00a0share with us what did you do in similar situations.<\/p>\n","protected":false},"excerpt":{"rendered":"

            A Scrum Master friend of mine missed Karaoke night on Saturday because she had to stay until midnight at work getting the release out of the door. Briefly, the story is like this: It was the release week and the new version of the application should have been on UAT environment on Thursday night. Even […]<\/p>\n","protected":false},"author":7,"featured_media":6465,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"footnotes":""},"categories":[1103,1128],"tags":[],"acf":[],"_links":{"self":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12081"}],"collection":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/comments?post=12081"}],"version-history":[{"count":0,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/posts\/12081\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media\/6465"}],"wp:attachment":[{"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/media?parent=12081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/categories?post=12081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mozaicworks.com\/wp-json\/wp\/v2\/tags?post=12081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}