Water-Scrum-Fall / Scrummerfall / Semi waterfall / Staggered Iterations for delivery

• Just small waterfalls
• Staggered iterations lead to
  • more technical debt
  • increase in rework
  • lower quality software
• moving from a 4-year iterative process to a 4-month one, you will see the value, but your process will be opaque and will only reduce your ability to deliver working software
• your cycle time will be reduced, but you can do so much better. Move all requirements for shipping your software into your Sprint, and If you need testing then it needs to be inside of the Sprint
• If you need to validate something outside of the Sprint; User Acceptance, Security audit, regulatory approval; make sure that all of the work is doing inside the Sprint, with no further work required from the DT
• many companies that are trying to move towards greater agility get trapped in the past by creating artificial silos based on skills. They believe that by creating a timebox for planning, development, QA and UAT, we can get closer to agility and move away from traditional models…
• …result is to enshrine that traditional staged model and step sideways on the path to agility, not forwards. In many cases, step backwards that will take many painful years to rectify
• This is often how organizations respond when they are told to “do agile”, and they end up figuring out how to not really change, and do the same thing that they have always done
• Model: Staggered iterations for delivery:
  • Staggered: R&D, Planning, Dev, QA, UAT, Delivery
• The problem with staggered iterations for delivery - diagram above
  • 18-week cycle from inception to delivery. That’s more than 4 months between ideation and delivery
  • a lag of 2 months:
    • to even get feedback from stating UAT to start to deliver
    • for all subsequent feedback between planning an iteration to getting the UAT from that planning
  • Worse this is the most expensive kind of feedback as the Coding and Testing teams have already moved on from the thing that is getting feedback, and the result of that feedback will be more expensive to implement: gathering the UAT feedback:
    • 4 weeks after the QA was initiated and 2 weeks since finished (1-2 iterations lag)
    • 6 weeks after the Dev was initiated and 4 weeks since finished (2-3 iterations lag)
    • 8 weeks after the Planning was initiated and 6 weeks since finished (3-4 iterations lag)
  • worse yet if QA finds something that needs to be fixed, we have maximized not only the cost to fix but the meantime to repair as the developers have moved on. gathering the QA feedback:
    • 4 weeks after the Dev was initiated and 2 weeks since finished (1-2 iterations lag)
  • Worse the lag of feedback from delivery: gathering the Delivery feedback
    • 16 weeks after the QA was initiated and 2 weeks since finished (7-8 iterations lag)
    • 14 weeks after the Dev was initiated and 4 weeks since finished (6-7 iterations lag)
    • 12 weeks after the Planning was initiated and 6 weeks since finished (5-6 iterations lag)
  • And what do they do with that feedback? How is it, prioritized? Do they quit what they are doing immediately and fix the previous iteration, or do they wait until after they deliver this one? What if they are blocking QA? Does QA sit around till the end of the iteration after the one they reported the problem in?
• The solutions to staggered iterations for delivery
  • foster teams over individuals
  • and make those teams responsible for the delivery of working software
  • cross-functional teams that can turn ideas into that working software
  • And we need to do it often
  • Solutions:
  • Cross-functional teams
    • create a team of individuals sufficient to complete the work with experts on hand as needed
    • all the skills required on each team to turn PBIs into working software each and every iteration
    • experts on hand for those tricky items but minimize the dependency on them
  • Asynchronous development
    • Ideally, you want all of the disciplines that you need to complete each PBI to work together to deliver the software
    • This is more than handing off between disciplines but moving towards everyone always working at any point in time
    • To achieve asynchronous development, you will need a modern source control system
      • Example: Visual Studio Team Services (VSTS)
  • Test first
    • not doing any work unless there is a measurable test that elicits that work
    • creating tests from acceptance criteria will make sure you have built what the customer wants
    • creating unit tests before code will make sure that DT are working on the most relevant problem, and that each line of code that they complete does exactly what they intended
    • The long-term benefit of this is to have an executable specification that will result in an error if a future change breaks existing functionality
  • Working software each iteration
    • If you don’t create working software at the end of each iteration, you have no way of knowing what really needs to be done to create a working increment
  • Quality Assurance requires no testing
    • If you consider that all testing is done as part of the sprint, then the only thing that needs to be done as part of the QA gate is to review the test results and coverage and determine the sufficiency of those results and coverage
  • NOTE: focus on automating everything from the moment a Software Engineer checks in code, to it being continuously delivered to production, any manual work is a risk