Loading...

Follow Agile Pain Relief—Certified ScrumMaster Train.. on Feedspot

Continue with Google
Continue with Facebook
or

Valid

Hardening Sprints are one of the most common kinds of Scrum Anti-Patterns: ways of addressing recurring problems that seem like effective solutions at the time but in fact hamper productivity or create more problems later on. Here we introduce why they are used, why they are not an effective design pattern, and how you can create more effective solutions. In software development work, a design pattern is a description of a solution to a recurring problem. It outlines the elements that are necessary to solve the problem, including context and the consequences of certain actions, without prompting the reader to solve the problem a specific way, leaving them with the agency to write code as they see fit. Patterns, when applied well and not overused, provide a guide to solving repetitive problems rapidly. A good pattern provides enough background information to help the reader appreciate where it is applicable, without declaring that is the best solution in all instances. Scrum, Agile, and Kanban, in this sense, are sets of behavioural design patterns. In the Scrum Community, we have Scrum PLOP (Pattern Language of Programs) that documents known patterns of effective behaviour. Unfortunately, we also regularly see recurring patterns of ineffective behaviour. These are called Anti-Patterns. “An anti-pattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn’t one.”  ~ Andrew Koenig[1] Scrum as an approach is already designed to deal with the unpredictable, without having to force exceptions. Whenever a team creates an exception, such as a special Sprint to solve a challenge, it creates an Anti-Pattern, which often results in a whole set of additional problems. The following is an exploration one of the most common Anti-Patterns: the “Hardening Sprint.” Anti-Pattern[2] Name: Hardening Sprint Aliases: Stabilization, Hangover, Release Sprint, or IP Iteration (Innovation and Planning Iteration in SAFe) Scale: Team and across multiple teams Related Anti-Patterns: Sprint 0, Separate Test Team; Component Teams; Technical Debt can be paid off later; Sprint Burndown Charts, Velocity is Important, …. Potential Solutions: Better Definition of “Done” Improve Engineering Practices Slowdown Background Teams new to Scrum often focus on getting as many User Stories finished as they can every Sprint. If they have good discipline, they write Unit Tests for their code. Once complete, they ship the feature off to their overburdened testers. In Sprint Review, the feature is accepted by the Product Owner. If defects are found, they’re added to the product backlog in a lower priority slot. While this sounds fine on the surface, trouble may be brewing. If they finish User Stories to the Definition of “Done” but that definition still leaves some things to be dealt with later, eventually it’s going to catch up to them. After five or six Sprints at this pace, they may elect to pause and have a “special” Sprint, or Hardening Sprint. They use this Sprint to do all of the work that they postponed in the working Sprints. The delayed work often includes tasks such as running a regression test suite, doing performance tests, and fixing defects. Usually, more defects are found than can be fixed. Once the Hardening Sprint is complete, the Product is released to Production. While this is common practice, it’s not in the spirit of Scrum. Scrum is intended to help teams learn the rigour and discipline to ship working software at the end of every Sprint. Clearly, having a Hardening Sprint as part of the process allows the Team to avoid dealing with that challenge, and therefore becomes an anti-pattern. Teams who have spent a long time working in a traditional fashion often elect for Hardening Sprints. This isn’t surprising since Hardening Sprints seem like a logical replacement for the testing and deployment phases that they’ve been used to. But that’s only because Teams new to Scrum haven’t yet felt the pain that is caused by these special Sprints, so they’re more likely to fall into the trap of thinking that they’re the solution to the difficult question of how to deliver working software at the end of every Sprint. Consequences Hardening Sprints are the developers’ version of “We’ll fix it in post.” They tend to decrease the readability of the code base because people have a habit[3] of delaying any tidy-up work until then. The messier the code is to read, the harder and more time-intensive it is to add new features or test existing ones. Many people call this Technical Debt.[4] It doesn’t take long before the team needs to add more time into the Hardening Sprint to get the work fully tested. Hardening Sprints have negative downstream consequences too. By delaying the release of a working product to the customer, we delay when they will pay us. Traditional or Waterfall approaches delay testing, writing documentation, etc. to the end of the process. When we delay work until a Hardening Sprint, we’re dragging a traditional approach into an Agile environment. The use of Hardening Sprints leads to: A larger volume of untested code – Many forms of testing (regression, performance, usability, etc.) are postponed until the Hardening Sprint. Defects difficult to resolve – The longer we delay in fixing them, the harder they are to fix, both because the person who wrote them forgot their intention and code base will have evolved so we may be relying on the defective behaviour elsewhere. An increase in defects that are either not discovered or discovered later – The more time that passes between writing code and testing it, the harder the defects are to find. In many cases, because of the ever-growing complexity, the defects are never found. Delay for the customer – In real Scrum, the customer can use the Product Increment (aka Working Software) at the end of every Sprint. With Hardening Sprints, they get access only after the Hardening Sprint. If Hardening Sprints happen every 5-6 Sprints, that means at least 3 months without new software and real engagement. An increase in the […]
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Kitchener-Waterloo—October 31-November 1, 2019 taught by certified Scrum Trainer Mark Levison.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Agile Pain Relief presents a two-day Certified Scrum Product Owner Workshop in Ottawa—October 24-25, 2019 taught by certified Scrum Trainer Mark Levison.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Agile Pain Relief presents a two-day Certified Scrum Product Owner Workshop in Toronto—October 3-4, 2019 taught by certified Scrum Trainer Mark Levison.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Toronto—September 19-20, 2019 taught by certified Scrum Trainer Mark Levison.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Edmonton—September 10-11, 2019 taught by certified Scrum Trainer Mark Levison.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Ottawa—September 5-6, 2019 taught by certified Scrum Trainer Mark Levison.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Ottawa—July 11-12, 2019 taught by certified Scrum Trainer Mark Levison.
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

A Scrum Sprint is incomplete when the Team can’t deliver the working features they committed to. We cover the reasons for this and how you can help your Team. Dramatis Personae Steve – a ScrumMaster and the hero of our story Paula – the Product Owner of Steve’s Team Tonia – the Team’s Quality Assurance specialist Brad – the Team’s Business Analyst Ian – the Team’s Business Logic programming specialist Last time we met Steve, he had discovered that the Product Backlog had not been discussed and estimated by the Product Owner and the Team. At Steve’s suggestion, the Team delayed the Sprint to have a Product Backlog Refinement meeting. The result was that all User Stories at the top of the Product Backlog were properly discussed with the Product Owner, Stories that were too large were split into smaller ones, and all the Stories now have estimates. They have now completed Sprint Planning and started their Sprint on developing features for the World’s Smallest Online Bookstore. The Sprint starts out looking okay… Coming out of the Sprint planning meeting, the Team has committed to five Stories. Their overall Sprint Goal is to get the customer’s book home: As a book buyer, I want to add my book(s) to my shopping cart so that I can purchase it – Story Points: 13 As a book buyer, I want to tell Amazon where I want my book(s) shipped so that I can receive it from a convenient location – Story Points: 8 As a book buyer, I want to see the price for my book(s) with shipping and tax so I can see whether I’m okay with the price – Story Points: 3 As a book buyer, I want to choose my payment type (MasterCard, Visa, Amex, or Paypal) so that I can pay for my book(s) – Story Points: 3 As a book buyer, I want to pay for my book(s) quickly so I can get my purchase home – Story Points: 13 As a book buyer, I want a confirmation message so I can see that the purchase was successful – Story Points: 2 The Team starts work on the first four Stories right away. Tonia (Quality Assurance specialist), spends the first few days working with Brad (Business Analyst). They clarify the acceptance criteria and she designs her test cases or test plan. When the acceptance criteria are unclear, they circle back with Paula (Product Owner) to get the best answers. … but then it became clear these were big problems they were tackling. By Monday, the fifth day of the Sprint,  Tonia had completed all of this work and was hungry for an application to test. In fact, she was wondering why she hadn’t seen anything yet. Lacking an application to test she found other things to do outside the team.[1] It wasn’t until Wednesday (Day 7) that she finally had the first story (add my book to my shopping cart) to test. Because it was such a big story and technically complex, it took much of the day just to get everything set up to run the test. By the end of the day though, she had found a dozen issues and shared them with Ian, the Team’s Business Logic programmer. “Add my book to my shopping cart” was clearly not ready. In the meantime, the other, smaller User Stories were piling up in front of Tonia, leaving her unable to keep up with testing. By the end of the Sprint, the Product Owner, Paula, had accepted only two User Stories as complete: “see the price for my books with shipping and tax” and “choose my payment type;”  a total of five Story Points out of the 42 they had committed to. Everything else was incomplete. What went wrong with the Sprint? Most teams will struggle when they start working with a new approach. The heroes of our story created three problems for themselves: Too Much Work in Progress; Overcommitment; and Pipelining 1) Too Much Work in Progress On the first day of the Sprint, the Team started work on four items at once. This divided the attention of the Team members and slowed work down on all of the items. At first, this result seems counter-intuitive – we expect that by starting more items, we will get them all done sooner. Yet, the experience of Toyota with its Lean Production System,[2] and repeated in the study “The Impact of Lean and Agile Quantified”, more Work In Progress (WIP) decreases the number of items that a team completes and increases the defect rate. Since the data we can gather is correlative (e.g. more WIP happens at the same time as the team gets less done), we have to speculate as to the reasons why. More WIP leads to: more Multitasking, reduced Focus time, more handoffs, and limits on collaboration. These combine to harm both throughput and quality. Does your grocery store limit Work in Progress? 2)    Overcommitment Each Team comes up with its own sense of what a Story Point[3] represents, so there won’t be common numbers. When helping people with estimation, I offer a guideline to help calibrate: for a size ‘2,’ or small story, the Team should select something that they believe represents 1/5th to 1/10th of the whole Team’s capacity to do work. I also suggest that the Team select a larger item that might take the whole Team an entire Sprint to complete and call that a ’13.’ Items that are larger than a ‘5’ typically have enough ambiguity within them that the Team is better off splitting the item before attempting work on it so they have a truer sense of the time that will be needed. If the heroes of our story had followed this guideline, they would have known that their over-commitment was quite large, and were realistically never going to be able to complete the Sprint. 3)    Pipelining The final problem is a more advanced concept and it is unlikely […]
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Agile Pain Relief presents a two-day Certified Scrum Master Workshop in Ottawa—June 10-11, 2019 taught by certified Scrum Trainer Mark Levison.
Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview