Agile Software Development: Identifying Risks

Question 1

Overall Risks to Track

Answer 1

Performance Risks
Slippage Risks
Priorities Risks
Project Risks

Question 2

Handling Risk in Agile

Answer 2

Visualize the risk: with dedicated risk board that is visually displayed

Prioritize the risk: by choosing riskier items and working on them first

Create user stories to mitigate the risk

Then we burn down the risk by working on the risk sooner rather than later, thereby mitigating the risk and making them disappear.

Question 3

How to spot risks before they become an issue

Answer 3

Daily standup

Trends

Question 4

Where should risks be listed for an Agile project?

Answer 4

IR/BVIR

Question 5

Slippage Risks

Answer 5

Slippage Risks: risks that impede a project and/or lead it to miss or ‘slip’ the deadline

Question 6

Burn down the risk

Answer 6

It means: prioritize risk, and work on it early so that you can determine very quickly if there are technical issues that will stop the project dead in its tracks

Question 7

How to adapt to changes

Answer 7

One way we adapt is by always prioritizing work in the backlog according to the value provided to the customer so that we are always working on the most important and valuable items

Question 8

How should unplanned work be dealt with?

Answer 8

It should be added to a Kanban board, with a WIP limit, and ranked using a numerical system. This ensures that the team is always working on the top priority.

If it is SCRUM, then it is added to the Product backlog and prioritized for the next sprint

Question 9

Kanban Leading indicators for potential problems

Answer 9

Cycle time increases

WIP limit violations

Question 10

SCRUM leading indicators for potential problems

Answer 10

Committed vs delivered: teams that are overcommitting and under-delivering

Varying sprint lengths

Increase in backlog mid-sprint

Question 11

Technical Debt

Answer 11

Technical Debt occurs when there is additional work or reworks that have to be done later, due to insufficient solutions that were implemented in the past.

Technical debt is a problem because it has to be paid back later, resulting in higher costs

Question 12

Where do we most commonly encounter Technical debt?

Answer 12

Older software code that is being modernized

Code not using microservices

Code that is not decoupled

Rushed Code

Lack of automated testing

Question 13

SLOC

Answer 13

software lines of code

Question 14

Combating Techincal Debt

Answer 14

Tackle a small amount of debt at a time

Use modern software development practices (microservices, TDD)

Peer review your code

Use code quality tools

Question 15

Code quality metrics

Answer 15

Code coverage ( 80%)
The automated test pass rate

Question 16

Mitigation strategies for dealing with a drop in quality metrics

Answer 16

Test-Driven Development (TDD) is recommended to increase quality in the future. TDD forces test to be written for all new user stories, thus increasing quality and code coverage

Peer reviews are also recommended to ensure that quality code is reviewed and shared with team members

Code quality standards are recommended to ensure code meets minimum quality standards, driving up quality

Technical debt needs to be reviewed, prioritized by the PO, and worked on in small chunks

Question 17

How much time should be spent each sprint on technical debt

Answer 17

10%

Question 18

When would it be better to tackle riskier items later?

Answer 18

When working with a new team, it might be better to prioritize easier items first to build confidence and to prevent demoralizing the team