Courageous Software Delivery
When an organization is terrified of taking risks, change management requirements can make it seem impossible to get the full benefits of Agile development. This talk covers strategies for lowering risk & meeting change management requirements with examples of a project at the US Treasury.
The goal of Agile is to deliver business value to customers. No matter how quickly new features are completed, they can’t be used by customers until they are actually deployed into production. Continuous delivery builds a technology and process pipeline to get business value efficiently from story to production with maximum automation, minimal time, and high reliability. By removing the risks and costs associated with manual deployment, organizations are free to deliver small incremental changes to running systems at much higher velocity and much lower risk than traditional approaches.
If you work on important applications in an organization with many change management requirements, it may seem like creating a continuous delivery pipeline is impossible. While it definitely isn’t easy, it is possible—even for government organizations.
In this talk, we are going to look at concrete ways to meet the governance requirements of large risk-averse organizations while decreasing the amount of time it takes to get capabilities and features into production. There is no magic formula, but we will look at examples of how to meet governance requirements with a high deployment velocity. In addition to examining technology that can lower risk and cut cycle time, we will also explore the human aspect of selling a new approach to an organization where the cost of mistakes is high and the reward of Agile deployment may not be fully understood. We will also look at some concrete examples of the return on investment of rapid deployment that can be used to help explain the value to your organization.
Outline/Structure of the Talk
- Development Risk
- Test Driven Development
- Behavior Driven Development
- Leveraging Cloud-based technologies
- Other areas of automation
- Lowering risk through only making small changes
- Examples from government based projects
- Treasury and small changes
- Examples of dealing with failures
- Deployment Risk
- Inverse risk profile of development risk
- Relation to DevOps
- Space X as a model to drive out risk
- Home generator risk mitigation example
- Resolving the conflict of mitigating both types of risk
- Moving to a common risk profile
- Lower risk = smaller changes = more frequent deployments = automation
- Selling lower risk to change management.
- Culture vs. Actual CM requirements
- Example of Treasury CM Culture and versioning
- Overcome resistance by giving people a chance to make meaningful contributions
- Removing impediments to flow
- Example of exceeding CM requirements at Treasury
- Example of standups as a replacement for change management meetings
- Example of lightweight use of JIRA to meet CM approval requirements
- Example of IRS reaction to incident vs. automated project
- The importance of leadership
- Leadership is about dealing with problems--not just making the right decisions up front.
- Teenage pirate example
- Our development processes are building the future
The key take-away is that you shouldn't give up just because it is hard to do rapid delivery. It is possible to delivery every few days all the way through to production even in government agencies with the most stringent change management processes. This talk with give examples and suggestions that worked well for the US Treasury, but the real value is in getting people to see that their project isn't some type of exception where it is impossible to do rapid delivery.
Anyone involved in developing or delivering software.
Prerequisites for Attendees
This talk is relevant for most backgrounds. It is helpful to be just a bit familiar with the idea of delivering software frequently. The talk is not particularly technical, but it touches on enough examples that people from a variety of backgrounds can easily see how the principles relate to their particular issues whether those are extremely technical in nature or more on the organizational side of things.