Developing and Delivering Products Professionally with Scrum results in high-quality software products delivered iteratively and incrementally with relatively high frequency. Key focus areas are Emergent Software Development, Managing Technical Risk, Optimizing Flow.
Developing and Delivering Products – Emergent Software Development
Emergent Software Development is the process of producing deliverables without defining the design or architecture upfront and allowing the design/architecture to materialize over time in order to be able to respond to systemic change quicker in a learning environment with little to no impact.
The best architectures, requirements, and designs emerge from self-organizing teams. Scrum embraces the Agile principle of emergent architecture and design. Architectural needs emerge due to functional and non-functional requirements. Agile relies on Just-in-Time and Just-Enough planning.
Let’s look at a few examples:
User stories – we don’t need every user story for the release prior to the first iteration. We need just enough user stories to get started.
Documentation – we certainly don’t need “just in case” documentation, but I also believe it is a fallacy to think agile teams can be effective with zero documentation. We need just enough documentation to make sure the team is successful.
Architecture – at the start of the project it doesn’t make sense to build out a fancy architecture that is going to change anyway. Agile teams should be striving to build just enough architecture to support the user stories in the queue.
Planning – at iteration planning we don’t look at things outside the iteration. We do just enough planning to make sure we can accomplish our goal for the iteration.
Collaboration – agile teams certainly have high levels of collaboration, but that is because that level is just enough to help them be successful.
Developing and Delivering Products- Managing Technical Risk
Risk is the possibility of loss, injury, or other adverse or unwelcome circumstance; a chance or situation involving such a possibility.
Financial risk – can we pay for it?
Business risk – will it be used? Does it solve the problem?
Technical risk – can it be made/build? (often in relation with finance, when a product becomes possible to build, but too expensive).
A few examples of risks in Agile projects are
The stakeholder requirements could be in conflict with each other.
The estimate is not based on historical throughput.
Team members are allocated to multiple projects.
The project was approved without team buy-in.
A 3rd party may not deliver their part.
Consequences of Technical Debt
As the level of technical debt rises, so does the severity of the consequences like
Unpredictable Tipping Point: At the tipping point, even small changes to the product become major occasions of uncertainty.
Increased Time to Delivery: Taking on technical debt means taking a loan today against the time required to do future work. When velocity slows, it takes longer to deliver new features and product fixes to customers. So, in the presence of high technical debt, the time between deliverables actually increases rather than decreases.
Huge Number of Defects: Products with significant technical debt become more complex, making it harder to do things correctly. The compounding defects can cause critical product failures to happen with alarming frequency. These failures become a major disruption to the normal flow of value-added development work. In addition, the overhead of having to manage lots of defects eats into the time available to produce value-added features.
Rising Development and Support Costs: As technical debt increases, development and support costs start rising.
Product Atrophy: As we stop adding new features or fixing defects that could rejuvenate our aging product, the product becomes less and less appealing to current and potential customers. As a result, the product starts to atrophy and simply ceases to be a viable option for most customers.
Decreased Predictability: For a product with high levels of technical debt, making any sort of prediction is nearly impossible. For example, estimates become bad estimates even for the most experienced team members. There is simply too much uncertainty surrounding how long something might take when dealing with a debt-ridden product. Consequently, our ability to make commitments and have a reasonable expectation of meeting them is seriously impaired. The business stops trusting anything development has to say, and customers stop trusting anything the business has to say!
Underperformance: Sadly, as technical debt increases, people come to expect increasingly lower development performance and therefore reduce their expectations of what is possible.
Universal Frustration: The unfortunate human consequence of high technical debt is that everyone in the value chain becomes frustrated.
Decreased Customer Satisfaction: Customer satisfaction will decrease as customer frustration increases. So the extent of the damage caused by technical debt is not just isolated to developers or even to the development organization as a whole. Even worse, the consequences of technical debt can substantially affect our customers and their perception of us.
Agile Principles Address these risks by
Transparency – Expose everything we are doing so we can see risks early
Collaborative planning – Harness the knowledge of the entire team and
see more risks
Customer involvement – Mitigate customer risk by involving them throughout the lifecycle
Risk Response in Agile Risk Management:
After identifying and assessing the risks in a project, the next step is to consider the risk responses. In broad terms, there are four types of response actions that are possible on the risks.
Avoid: Eliminating the threat of risk by eliminating the cause.
Mitigate: Reducing the consequences of risk by reducing its severity of impact or likelihood of occurring.
Transfer: Accepting the risk if it occurs.
Accept: Assigning the risk to another party by purchasing insurance or subcontracting.
Developing and Delivering Products- Optimizing Flow
Each Scrum Team must create its definition of workflow and it must contain a definition of how Work in Progress (WIP) will be limited.
Work in Progress (WIP): The number of work items started but not finished.
Cycle Time: The amount of elapsed time between when a work item “starts” and when a work item “finishes.”
Work Item Age: The amount of elapsed time between when a work item “started” and the current time.
Throughput: The number of work items “finished” per unit of time. Note the measurement of throughput is the exact count of work items.