More on this book
Community
Kindle Notes & Highlights
by
Jez Humble
Read between
July 3 - July 3, 2017
Delay. By calculating cost of delay for each feature, we no longer rely solely on a product owner to estimate the business value for the stories in the backlog, which is a poor way to prioritize since this person must constantly recalculate in order to take into account the time sensitivity of business value. Instead, given that we have limited capacity, we think of prioritization as choosing what to delay. When development capacity becomes available, the team simply picks the item with the highest delay cost at that time. This is a key advantage of using Cost of Delay: following the Principle
...more
Cost of Delay provides us with an economic argument for limiting work in process.
The time sensitivity of the cost of delay is captured in an urgency profile. Urgency profiles that might be used in real life for Task A and Task B are shown in Figure 7-10. Cost of delay, on the y axis, represents the amount of money it costs per unit time to delay the work. To calculate the total delay cost, we measure the shaded area under the graph.
The most important thing to bear in mind is that we are aiming for accuracy, not precision, in our estimates.
If the uncertainty around the cost of delay is very high, this means we are in the “explore” domain and must test our assumptions, perhaps using one of the techniques, such as modeling a key metric with Monte Carlo simulations or testing business hypothesis with MVPs, discussed in Part II.
Applying Cost of Delay across the enterprise allows us to decentralize decision making and bring decisions under economic control.
Its purpose is to improve the quality of demand by enabling us to identify and avoid lower-value work whilst shortening lead times for high-value work.
If you don’t have large queues and too much work, using Cost of Delay will likely provide little overall value.
The ultimate solution for the deficit of throughput — and thus productivity — is to reduce lead times overall by reducing batch sizes, managing work in process, and reducing the cost of delivering value to customers.
In terms of measuring value, there is no substitute for shipping and getting real customer feedback.
In high-performing organizations, leadership and management has a sharp focus on the value the organization is creating for its customers.
An effective innovation capability relies on being able to frequently test ideas with real users. Crucially, the rate at which we can learn, update our product or prototype based on feedback, and test again, is a powerful competitive advantage.
Despite the name, continuous delivery is not about deploying to production multiple times a day. The goal of continuous delivery is to make it safe and economic to work in small batches. This in turn leads to shorter lead times, higher quality, and lower costs.
Continuous delivery is the ability to get changes — experiments, features, configuration changes, bug fixes — into production or into the hands of users safely and quickly in a sustainable way.
We must constantly monitor and reduce the lead time for getting changes into the hands of users.
We reduce lead time by working to simplify and automate the build, deploy, test, and release process.
The team is not allowed to say they are “done” with any piece of work until their code is in trunk on version control and releasable
The solution is for all developers to work off trunk and to integrate their work into trunk at least once per day.
Continuous integration is the practice of working in small batches and using automated tests to detect and reject changes that introduce a regression.
It is, in our opinion, the most important technical practice in the agile canon, and it forms the foundation of continuous delivery, for which we require in addition that each change keeps the code on trunk releasable.
The main objection to continuous integration comes from developers and their managers.
That means it may take longer, at first, to declare stories “dev complete.” This may, in turn, drive the development velocity down and create the impression that the team’s efficiency has decreased — raising the blood pressure of development managers.
However, we should not be optimizing for the rate at which we declare things “done” in isolation on a branch. We should optimize for the overall lead time — the time it takes us to deliver valuable software to users.
Achieving CI is not simply a case of installing and running a CI tool; it is a mindset.
At Google, for example, anyone is empowered to revert a bad change in version control, even if it was made by someone on a different team: they prioritize keeping the system working over doing new work.
The job of the deployment pipeline is to evaluate every change made to the system, to detect and reject changes which carry high risks or negatively impact quality, and to provide the team with timely feedback on their changes so they can triage problems quickly and cheaply.
All changes to any system — or the environments it runs in — should be made through version control and then promoted via the deployment pipeline.
That includes not just source and test code but also database migrations and deployment and provisioning scripts, as well as changes to server, networking, and infrastructure configurations.
Auditors love the deployment pipeline because it allows them to track every detail of exactly which commands were run on which boxes, what the results were, who approved them and when, and so forth.
approval processes external to development teams do little to improve the stability of services (measured in terms of time to restore service and percentage of failed changes), while acting as a significant drag on throughput (measured in terms of lead time for changes and change frequency).
The data suggests that it is time to reconsider the value provided by heavyweight change control processes. Peer review of code changes combined with a deployment pipeline provide a powerful, safe, auditable, and high-performance replacement for external approval of changes.
Deployment is the installation of a given version of a piece of software to a given environment. The decision to perform a deployment — including to production — should be a purely technical one. Release is the process of making a feature, or a set of features, available to customers. Release should be a purely business decision.
Figure 8-3. Blue-green deployments, courtesy of Martin Fowler
“dark launching.” In his talk on the Facebook release process, release manager Chuck Rossi says that all the major features that will launch in the next six months are already in production — you just can’t see them yet.
Developers protect new features with “feature flags” so that administrators can dynamically grant access to particular sets of users on a per-feature basis.
Figure 8-4. Deployment g-forces, courtesy of Paul
The difficulty in defining quality is to translate future needs of the user into measurable characteristics, so that a product can be designed and turned out to give satisfaction at a price the user will pay. Walter Shewhart
Instead of coming up with requirements or use cases and putting them into a backlog so that teams build them in priority order, we describe, in measurable terms, the business outcomes we want to achieve in the next iteration.
creating target conditions based on customer and organizational outcomes as part of our iteration planning process, in addition to process improvement target conditions. This enables us to use program-level continuous improvement for product development too, by adopting a goal-oriented approach to requirements engineering.
Organizations can only move fast at scale when the people building the solutions have a deep understanding of both user needs and business strategy and come up with their own ideas.
It’s also essential to ensure that target conditions have measurable acceptance criteria, as shown in Figure 9-1.
We begin an impact map with a program-level target condition. By stating a target condition, including the intent of the condition (why we care about it from a business perspective), we make sure everyone working towards the goal understands the purpose of what they are doing, following the Principle of Mission. We also provide clear acceptance criteria so we can determine when we have reached the target condition.
The first level of an impact map enumerates all the stakeholders with an interest in that target condition.
The second level of an impact map describes possible ways the stakeholders can help — or hinder — achieving the target condition.
These changes of behavior are the impacts we aim to create.
The possible solutions proposed in the impact map are not the key deliverable. Coming up with possible solutions simply helps us refine our thinking about the goal and stakeholders.
For this tool to work effectively, it’s critical to have the right people involved in the impact-mapping exercise.
One of the most important goals of impact mapping is to create a shared understanding between stakeholders, so not involving them dooms it to irrelevance.
