Managing Products with Agility [P1]: Managing Products with Agility/Forecasting and Release Planning - Release Planning and Predictable Delivery

Question 1

What does leadership need to decide on so that devs can focus on developing and devs shouldn’t make those calls?

Answer 1

Decide on quality

Question 2

What is needed in order to deliver usable increments?

Answer 2

Rythym

Question 3

Why is software so unpredictable

Answer 3

• All software development is product development
• Manufacturing lives in the predictive world
• With software everything that we create takes its own amount of time
• In software development we are always doing new product design, therefore, we have no certainty…and this often results in chaos.Software lives in the empirical world.
• by looking at our history of delivery for similar things, make a pretty goodforecast…
• expend effort to make that forecast as accurate as possible while accepting that more time spent planning does not necessarily affect the accuracy of that forecast.

Question 4

What are the two classifications of size as per the no-estimates movement?

Answer 4

small &fitsin a Sprint, ortoo bigto fit in a Sprint

Question 5

What are the problems with a lack of quality of code?

Answer 5

• TB - leads to
  
  • teams increasingly have to spend more time struggling with the complexity of your software rather than on new features
  • increasing number of bugs found in production - limits time on future features

Question 6

How do you handle TD?

Answer 6

stop creating it, and then pay a little back each iteration

Question 7

If however, you are so drowning in technical debt that you cant create working software at the end of the iteration, then…?

Answer 7

1. Create a[short measurable checklist]that mirrors minimum releasable product (Defenition of Done)
2. Stop adding new features andmake your product meet that checklistand release your product
3. While you have an increment of working software (Sprint)
   
   1. Work to create something of value (Increment)
      
      1. Work towards a new goal while meeting the DOD (Sprint Goal)
      2. Leave things better than you found them (Engineering Excellence)
   2. Review that thing of value with your stakeholders (Sprint Review)
      
      1. Get feedback on at least one new thing for stakeholders
      2. Update the Backlog to reflect this new information
   3. Reflect on how you worked with your entire team (Sprint Retrospective Kaizen)
      
      1. Is the quality increasing?
      2. Is the DOD increasing?
      3. What can we change to make things better?
4. Go to #1

Question 8

There are a number of strategies that can help you both stop creating and start paying back technical-debt (8)

Answer 8

1. Sufficient requirement - Follow the INVEST (Independent, Negotiable, Valued, Estimable, Small, Testable ) model for every single thing that you ask the team to deliver. Do backlog refinement
2. Developerschoose what they can deliver - devs can “reject” (actional feedback and continuous improvement) if it’s too big or they don’t understand it
3. Definition of Done (DoD)
4. Test First - e.g. TDD, ATDD
5. Fixed-length iterations - reject idea of staggered iterations
6. No separate teams - devs own entire lifecycle e..g include DevOps in team, don’t separate out
7. Manage dependencies - minimise dependencies where possible
8. Use a modern source control system - more than just code management, it should include all of the goodies talked about in DevOps practices and beyond