Leading the Transformation – Applying Agile and DevOps Principles at Scale

Top Three Things I learned

  1. I liked his definition of legacy, that which requires brute force manual effort to deploy
  2. I liked what he specified in what was missing with a bottoms up approach.  I agree with his concept that the first order issue is how teams come together and how the teams work is second order.
  3. There are lots of good one-liners out of this book.  Perhaps my favorite is “organizations need to decide whether their primary objective is to deliver long-term accurate plans to its executives or if it is to deliver business value to its customers.
NOTES: Chapter 1: Understanding the Transformation

SUMMARY: Short, but dense chapter that gives the outline and motivations for this book and these concepts. Most important is the figure which ties together much of ht ebook.  The chapter ends with a picture of how the transformation looks.

IDEA: Legacy is anything that requires brute force manual effort to deploy.

CONCEPT: Overall productivity

  1. 1st order effect is how the teams come together
  2. 2nd order effect is how the teams work

CONCEPT: Key figures

  1. Business Objective
  2. Enterprise Level continuous integration
  3. Business objectives continuous improvement
  4. Applying DevOps principles at scale

CONCEPT: Transformational Shifts

  1. Stable Trunk
  2. Dev + Ops use common tools and environment
  3. Consensus on Definition of Done at Release
  4. Defects free
  5. Test automation in place
  6. Process for change
NOTES: Chapter 2: Challenges with Scaling Agile Teams

SUMMARY: A very short chapter that stresses what most people miss in agile transformation is to give objectives at the enterprise and flexibility at the team level.

IDEA: Ask what is the organization’s capacity to change

CONCEPT: What is missing is a bottoms up approach

  1. No Plan for enterprise releases
  2. No enterprise backlog
  3. Enterprise definition of done
  4. Lots of organizational change
NOTES: Chapter 3: Business Objectives and Crucial First Steps

SUMMARY: This chapter screams value stream mapping

IDEA: His goal was never to do Agile, it was to continuously improve.

CONCEPT: Approach

  1. Get a clear set of business objectives
  2. Determine where to start the transformation
  3. Use activity-based accounting and cycle time approach. Alternative go for the usual suspects, maintenance and planning.

IDEA: In large and small companies, writing code is the same, its integrating and getting in production that is different.

CONCEPT: Business objectives orient you to:

  1. Where you are
  2. Where you are going
  3. Expected benefits
NOTES: Chapter 4: Enterprise-Level Continuous Improvement

SUMMARY: This is a very short chapter which basically says in very simple terms continuously improve.  They give a sample framework.

CONCEPT: Enterprise-level continuous improvement

  1. End-to-end view of the value chain
  2. Create a culture of continuous improvement where enterprise-level objectives are set and goals are defined for.

IDEA: The ability to fix things is dependent on transparency which is dependent on trust.

NOTES: Chapter 5: Agile Enterprise Planning

SUMMARY: A lot packed into this chapter.  Because software is so flexible you must embrace change which means you must have capacity to change.  The chapter makes a strong case for not looking in you most flexible asset by building in capacity. It ends with a brief but important discussion on requirement inventory management.  Oh I should also mention that it has a case study that can be summed up by saying we will decrease value delivery if we emphasize planning value.

IDEA: Software is infinitely flexible. It’s called SOFTware for a reason.

IDEA: Software if managed and developed correctly is less expensive and easier to change.  The problem is that most software is managed using the same techniques that are applied to other inflexible disciplines, thus robbing ourselves of software’s greatest benefit: flexibility.

IDEA: Discovery is a variable the less times you have done something the more discovery and the less planning.

IDEA: With waterfall you have a choice of 2 options to meeting your schedule, 1) create a buffer or 2) death march.  Neither addresses uncertainty that will happen.

IDEA: Don’t lock in your most flexible asset to commitments for features that are not likely to meet your business objectives.

CONCEPT: Use time-horizons to build in capacity

  1. Long-term (Year) : 50% of capacity
  2. Mid-term (Months): 80% of capacity
  3. Short-term (weeks): 100% of capacity

CONCEPT: Changes to the Planning Process

  • Build in capacity with different time horizons
  • Minimize Requirements Inventory
    • No wasted effort planning if never came to be
    • When change happens not a log of requirements to be re-worked.

 

NOTES: Chapter 6: Business Objectives Specific to Scaling DevOps

SUMMARY: A very short chapter with 1 concept and a couple of bullet points.  Concept: Manufacturing should be free.

CONCEPT: Business objectives

  1. Improve the quality and speed of feedback for developers
  2. Reduce the time and resources required to go from functionality complete or release branching to production
  3. Improve the repeatability of the build, deploy, and test process
  4. Develop an automated deployment process that will enable you to quickly and efficiently find any deployment or environment issues
  5. Remove the duplication of work that comes from supporting multiple branches of similar code.
NOTES: Chapter 7: Creating a Culture of Trunk Development

SUMMARY: A very short chapter to say branching is evil and should be avoided at all costs.

NOTES: Chapter 8: Ensuring a Solid Foundation

SUMMARY: Covers a few fundamental issues before moving onto the next chapter specifically a long on automated testing.

CONCEPT: Fundamentals

  1. Clean Architecture
  2. Independent components
  3. Test automation

CONCEPTS: Steps

  1. Architecture: allows for quickly developing, testing, and deploying independently
  2. Build Process: different components cannot have build dependencies
  3. Test automation: you can’t keep software stable without test automation
  4. Test environment: environments or simulators
  5. Designing Automated Tests for Maintainability: Recommends pairing tester with developer
  6. Creating a test results database: manage and report test reports
  7. Designing automated test to quickly localize defects: isolation of failed event is easier.
  8. Using test automation as documentation
NOTES: Chapter 9: Achieving Decentralized Control

SUMMARY: This chapter attempts to summarize Jez Humbles’s book.  It starts with a list of terms and definitions.  The next sub-part is on continuous delivery architecture, then post-deployment validation and finally CD.

CONCEPT: Configuration is under revision control to ensure repeatability.

CONCEPT: Core pieces of CD:

  • Continuous Integration
  • Scripted environments
  • Scripted deployments
  • Evolutionary database design
  • Test automation
  • Deployment pipeline
  • Orchestrator

TERM: Continuous Delivery: Automation (as much as possible) of configuration, deployment, and testing

TERM: Continuous Integration: A process that monitors the source code management and triggers a build.

TERM: Scripted environment: Scripts are created to configure everything from the O/S to the container.

TERM: Scripted Deployment: Process of scripting the deployments across all environments.

TERM: Evolutionary database design: Managing database changes to ensure that schema changes won’t ever break your application.

TERM: Deployment pipeline: defines how new code is integrated to the system deployed.

TERM: Orchestrator: Tool that coordinates all of the automation.

CONCEPT: One common script that uses variables for everything.

NOTES: Chapter 10: Designing the Deployment Pipeline

SUMMARY: Some very complex ideas are presented in just a few pages.  Much more information here would have been useful and the lack of it reduces the value of the book.

CONCEPT: Quickly locating the offending code down to the fewest number of developers possible is the basic principle that should drive the design.

CONCEPT: Testing layers.  First run unit tests, static code analysis, second run service or api tests, lastly test the User Interface.

CONCEPT: Testing stages.

  1. Build and test as much of the system as possible
  2. Break down the problem by using service virtualization to isolate different parts of the system
  3. Pick a subset of testing for fast feedback before promoting to later stages for more extensive testing
NOTES: Chapter 11: Improving Stability Over Time

SUMMARY: Just a few concepts and many words presented here.

CONCEPT: What Release Management should strive for to create a stable release

  • All features signed off on
  • No open defects
  • Test automation
    • acceptable level of coverage
    • acceptable passing rates

 

NOTES: Chapter 12: Getting Started

SUMMARY: Four key concepts are listed here.

CONCEPT: Key concepts

  1. Getting developers to own ensuring every check in to trunk is stable in a production like environment as job #1
  2. Getting development and operation teams using common tools and environments to align them on a common objective
  3. Getting the entire organization to agree that the definition of done at the release branch is that the feature is signed off, defects free, and the test automation is ready in term of test coverage and passing rates.
  4. Getting the organization to embrace the unique characteristics of software and design of a planning process that takes advantage of its flexibility.
Advertisement