Technical debt is a metaphor coined by Ward Cunningham in 1992. This concept refers to the work that needs to be done so that a software development project could be considered as “complete”. Could you try to measure your amount of technical debt? Could you use some tools to do this? These are some of the questions that this article explores.
This article propose a practical approach on how to estimate risks during Agile planning. The possible risk causes are divided into five areas: acquisition, supply, development, support, and organizational.
Both traditional project management and Agile development approaches rely on several techniques, such as bottom-up estimation, order of magnitude, planning poker, affinity estimation, relative sizing, and parametric estimation at various stages. But the most important derivative of all these techniques is to ensure the central tendency of the estimate as perceived by the team closest to the implementation. When team members vary on the perceived requirements of user stories, this is an indication of ambiguous requirements or unclear scope leading to questionable "done" criteria. Here is where the proven PERT method can be applied even in an Agile environment.
Focusing on two agile architecting methods that provide rapid feedback on the state of agile team support: architecture-centric risk factors for adoption of agile development at scale and incremental architecture evaluations.
There is no definite consensus on the need for risk management within the Agile method. This has led many to believe that risk management is irrelevant in an iterative model. Some follow the approach of ignoring risks until they manifest into issues; they then manage them through the natural sprint progression. I feel it's better to manage risks proactively in Agile.
Risk refers to uncertain future conditions or circumstances that may adversely impact a project if they occur. A risk represents the possibility, not the certainty, of a future event affecting the success of a software development project. Risk is inherent in all projects. By effectively managing risk, the project team can reduce the likelihood that an adverse event will occur and the impact on the project should such an event occur. Risk management is a repeatable, structured process that identifies and systematically addresses risks to minimize their effect on projects.
A prevailing belief among Agile and Scrum proponents is that “a great deal of explicit risk management becomes unnecessary when a software development project uses an agile approach.” In my experience, this is a false and dangerous assumption. Project risk is a hungry leopard ready to devour the unprepared. Fleet-footed agilists and die-hard waterfallists alike.
Managing software risk in the supply chain is in large part about discovering and understanding the vulnerabilities that might exist in code that you might buy as standalone applications or integrate into other systems or products.