A pleasant walk through computing

Comment for me? Send an email. I might even update the post!

Accelerate Book Notes

Work-in-progress! New chapter notes and quotes will be added as I complete reading them!

History

  • 2018-10-14 Chapters 1-5 released

This is a chapter-by-chapter collection of quotes and notes on the book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, Nicole Forsgren PhD, Jez Humble, Gene Kim.

Any quotes from the book in this article are copyrighted. My intent is to provide an overview of what struck me in the material, and to encourage any visitor to purchase and read this important work.

Quick Reference: Capabilities to Drive Improvement

Quotes

Our research has uncovered 24 key capabilities that drive improvements in software delivery performance. This reference will point you to them in the book.

The capabilities are classified into five categories:

  • Continuous delivery
  • Architecture
  • Product and process
  • Lean management and monitoring
  • Cultural

CONTINUOUS DELIVERY CAPABILITIES

  1. Version control: Chapter 4
  2. Deployment automation: Chapter 4
  3. Continuous integration: Chapter 4
  4. Trunk-based development: Chapter 4
  5. Test automation: Chapter 4
  6. Test data management: Chapter 4
  7. Shift left on security: Chapter 6
  8. Continuous delivery (CD): Chapter 4

ARCHITECTURE CAPABILITIES
9. Loosely coupled architecture: Chapter 5
10. Empowered teams: Chapter 5

PRODUCT AND PROCESS CAPABILITIES
11. Customer feedback: Chapter 8
12. Value stream: Chapter 8
13. Working in small batches: Chapter 8
14. Team experimentation: Chapter 8

LEAN MANAGEMENT AND MONITORING CAPABILITIES
15. Change approval processes: Chapter 7
16. Monitoring: Chapter 7
17. Proactive notification: Chapter 13
18. WIP limits: Chapter 7
19. Visualizing work: Chapter 7

CULTURAL CAPABILITIES
20. Westrum organizational culture: Chapter 3
21. Supporting learning: Chapter 10
22. Collaboration among teams: Chapters 3 and 5
23. Job satisfaction: Chapter 10
24. Transformational leadership: Chapter 11

Preface

Quotes

Beginning in late 2013, we embarked on a four-year research journey to investigate what capabilities and practices are important to accelerate the development and delivery of software and, in turn, value to companies.

Chapter 1 - Accelerate

Notes

Companies, even big ones, are moving away from big projects, instead using small teams using small development cycles.

Software is at the heart of (most of) these transformations. [I don't personally believe that software is the end-all of business improvement, but it's true that many businesses don't realize how much software drives them.]

Maturity models don't work. Capability models do.

None of these factors predict performance:

  • age and technology used for the application (for example, mainframe “systems of record” vs. greenfield “systems of engagement”)
  • whether operations teams or development teams performed deployments
  • whether a change approval board (CAB) is implemented

Quotes

DevOps emerged from a small number of organizations facing a wicked problem: how to build secure, resilient, rapidly evolving distributed systems at scale.

A recent Forrester (Stroud et al. 2017) report found that 31% of the industry is not using practices and principles that are widely considered to be necessary for accelerating technology transformations, such as continuous integration and continuous delivery, Lean practices, and a collaborative culture (i.e., capabilities championed by the DevOps movement).

Another Forrester report states that DevOps is accelerating technology, but that organizations often overestimate their progress (Klavens et al. 2017). Furthermore, the report points out that executives are especially prone to overestimating their progress when compared to those who are actually doing the work.

To summarize, in 2017 we found that, when compared to low performers, the high performers have:

  • 46 times more frequent code deployments
  • 440 times faster lead time from commit to deploy
  • 170 times faster mean time to recover from downtime
  • 5 times lower change failure rate (1/5 as likely for a change to fail)

Chapter 2 - Measuring Performance

Notes

The academic rigor of this book is exceptionally high.

Three ways to masure performance that don't work: lines of code, velocity, and utilization.

Two characteristics of successful measures: focus on global outcomes, and focus on outcomes not output.

Lead Time is "the time it takes to go from a customer making a request to the request being satisfied." The authors focused on the delivery part of lead time--"the time it takes for work to be implemented, tested, and delivered."

The stats on "the impact of delivery perofrmance on organization performance" shows that software development and IT are not cost centers; they can provide a competitive advantage.

It's important to distinguish between strategic and non-strategic software. Strategic software should be kept in-house. See Simon Wardley and the Wardley mapping method.

Quotes

There are many frameworks and methodologies that aim to improve the way we build software products and services. We wanted to discover what works and what doesn’t in a scientific way,...

Most of these measurements focus on productivity. In general, they suffer from two drawbacks. First, they focus on outputs rather than outcomes. Second, they focus on individual or local measures rather than team or global ones.

In our search for measures of delivery performance that meet these criteria, we settled on four: delivery lead time, deployment frequency, time to restore service, and change fail rate.

Astonishingly, these results demonstrate that there is no tradeoff between improving performance and achieving higher levels of stability and quality. Rather, high performers do better at all of these measures. This is precisely what the Agile and Lean movements predict,...

It’s worth noting that the ability to take an experimental approach to product development is highly correlated with the technical practices that contribute to continuous delivery.

The fact that software delivery performance matters provides a strong argument against outsourcing the development of software that is strategic to your business, and instead bringing this capability into the core of your organization.

The measurement tools can be used by any organization,...

However, it is essential to use these tools carefully. In organizations with a learning culture, they are incredibly powerful. But “in pathological and bureaucratic organizational cultures, measurement is used as a form of control, and people hide information that challenges existing rules, strategies, and power structures. As Deming said, 'whenever there is fear, you get the wrong numbers'”

Chapter 3 - Measuring and Changing Culture

Notes

Not only is culture measurable for the purposes of the book, but the authors learned that DevOps can "influence and improve culture."

Westrum's three characteristics of good information:

  1. Provides the needed answers
  2. Timely
  3. Presented so can be used effectively

A good culture:

  • Requires trust and cooperation
  • Has higher quality decisionpmaking
  • Teams do better job with their people

John Shook, in a video on the Lean Transformation Model, makes it clear that the approach is value-driven approach, the "true north" of any situation. John Shook Explains the Lean Transformation Model - YouTube

Quotes

Ron Westrum's three kinds of organizational culture

Pathological (power-oriented) organizations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
Bureaucratic (rule-oriented) organizations protect departments. Those in the department want to maintain their “turf,” insist on their own rules, and generally do things by the book — their book.
Generative (performance-oriented) organizations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do.

Table 3.1 Westrum's Typology of Organizational Culture.

Pathological (Power-Oriented) Bureaucratic (Rule-Oriented) Generative (Performance-Oriented)
Low cooperation Modest cooperation High cooperation
Messengers “shot” Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure leads to scapegoating Failure leads to justice Failure leads to inquiry
Novelty crushed Novelty leads to problems Novelty implemented

Using the Likert-scale questionnaire

To calculate the “score” for each survey response, take the numerical value (1-7) corresponding to the answer to each question and calculate the mean across all questions. Then you can perform statistical analysis on the responses as a whole.

Westrum’s theory posits that organizations with better information flow function more effectively.

Thus, accident investigations that stop at “human error” are not just bad but dangerous. Human error should, instead, be the start of the investigation.

“ what my... experience taught me that was so powerful was that the way to change culture is not to first change how people think, but instead to start by changing how people behave — what they do” --John Shook, leader in lean manufacturing

Our research shows that Lean management, along with a set of other technical practices known collectively as continuous delivery (Humble and Farley 2010), do in fact impact culture,...

Chapter 4 - Technical Practices

Notes

CD practices will help improve culture. However, implementing the practices "often requires rethinking everything".

Keeping system and application configuration in version control is more important to delivery performance than keeping code in version control. (But both are important).

Quotes

Continuous delivery is a set of capabilities that enable us to get changes of all kinds — features, configuration changes, bug fixes, experiments — into production or into the hands of users safely, quickly, and sustainably. There are five key principles at the heart of continuous delivery:

  1. Build Quality In
    Invest in building a culture supported by tools and people where we can detect any issues quickly, so that they can be fixed straight away when they are cheap to detect and resolve.
  2. Work in Small Batches
    By splitting work up into much smaller chunks that deliver measurable business outcomes quickly for a small part of our target market, we get essential feedback on the work we are doing so that we can course correct.
  3. Computers perform repetitive tasks; people solve problems
    One important strategy to reduce the cost of pushing out changes is to take repetitive work that takes a long time, such as regression testing and software deployments, and invest in simplifying and automating this work.
  4. Relentlessly pursue continuous improvement
    The most important characteristic of high-performing teams is that they are never satisfied: they always strive to get better.
  5. Everyone is responsible
    in bureaucratic organizations teams tend to focus on departmental goals rather than organizational goals. Thus, development focuses on throughput, testing on quality, and operations on stability. However, in reality these are all system-level outcomes, and they can only be achieved by close collaboration between everyone involved in the software delivery process. A key objective for management is making the state of these system-level outcomes transparent, working with the rest of the organization to set measurable, achievable, time-bound goals for these outcomes, and then helping their teams work toward them.

A key goal of continuous delivery is changing the economics of the software delivery process so the cost of pushing out individual changes is very low.

In order to implement continuous delivery, we must create the following foundations:

  • Comprehensive configuration management
    It should be possible to provision our environments and build, test, and deploy our software in a fully automated fashion purely from information stored in version control.
  • Continuous integration
    High-performing teams keep branches short-lived (less than one day’s work) and integrate them into trunk/master frequently. Each change triggers a build process that includes running unit tests. If any part of this process fails, developers fix it immediately.
  • Continuous testing
    Automated unit and acceptance tests should be run against every commit to version control to give developers fast feedback on their changes. Developers should be able to run all automated tests on their workstations in order to triage and fix defects.

Implementing continuous delivery means creating multiple feedback loops to ensure that high-quality software gets delivered to users more frequently and more reliably.

Chapter 5 - Architecture

Notes

See the quote below, it's important that teams be loosely coupled, not just the architecture. But how does this apply to a small software/IT shop of, say a half dozen employees?

I see autonomy of teams coming up quite a bit, not having to ask for permission to change from someone outside the team, and also that changes don't strongly affect other teams. This is a result of loose-coupling.

So, it's interesting that good information flow is important, but that teams shouldn't need to overly communicate in order to do their work.

The authors make a great point about service-oriented architecture and microservices, that these both can enable the desired outcome of testability, but, they don't guarantee it. The team has to be vigilant about ensuring the ability to independently test services.

A good, loosely-coupled architecture allows not just the software but the teams to scale. Contrary to assumptions, adding employees when there's a proper software/team architecture leads to increasing deployment frequency.

I've been in the camp that wants to reduce or at least make tooling consistent. I think there's still some value in that from a maintainability perspective. However, using the better tool for the job apparently has more value. I don't think the authors are advocating a gung-ho or cavalier approach, though.

Quotes

We found that high performance is possible with all kinds of systems, provided that systems—and the teams that build and maintain them—are loosely coupled.

We discovered that low performers were more likely to say that the software they were building—or the set of services they had to interact with—was custom software developed by another company (e.g., an outsourcing partner).... In the rest of the cases, there was no significant correlation between system type and delivery performance. We found this surprising: we had expected teams working on packaged software, systems of record, or embedded systems to perform worse, and teams working on systems of engagement and greenfield systems to perform better. The data shows that this is not the case.

This reinforces the importance of focusing on the architectural characteristics, discussed below, rather than the implementation details of your architecture.

Those who agreed with the following statements were more likely to be in the high-performing group:

  • We can do most of our testing without requiring an integrated environment.
  • We can and do deploy or release our application independently of other applications / services it depends on.

The goal is for your architecture to support the ability of teams to get their work done — from design through to deployment — without requiring high-bandwidth communication between teams.

When teams can decide which tools they use, it contributes to software delivery performance and, in turn, to organizational performance.

That said, there is a place for standardization, particularly around the architecture and configuration of infrastructure.

Another finding in our research is that teams that build security into their work also do better at continuous delivery. A key element of this is ensuring that information security teams make preapproved, easy-to-consume libraries, packages, toolchains, and processes available for developers and IT operations to use in their work.

Architects should focus on engineers and outcomes, not tools or technologies.... What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes and enable the behaviors we care about. What is important is enabling teams to make changes to their products or services without depending on other teams or systems.

Getting Started With Software (and Business and Life) Skills

Why Am I Writing This?

I recently had a delightful meeting with a 29-year-old violinist who is making a career change into software. She's brim-full of ideas and excitement, has an entrepeneurial spirit, and is doing something very smart: asking other people what they think. She's going to get loads of advice, most of it well-meaning crap, which could very well include my information.

Her story spoke to me, because I'm a violinist, I got my first IT job when I was thirty, and I've been successfully self-employed. I've struggled with everything I'm suggesting.

What interested me was how to answer a question: What do I think a beginning software engineer needs to know?

The answer has almost nothing to do with programming. Oh, sure, I could list a whole bunch of programming resources that even I haven't read. But she'll eventually find those. What I think, based on twenty-five years of experience in the industry (plus fifteen years in retail, food service, and other jobs before that), is that a successful, fulfilled person needs to:

  1. Learn how to learn
  2. Know what it means to know something
  3. Communicate well as a collaborator
  4. Savor life

Are there skills specific to being a programmer? Sure. See Appendix A. But I think they don't matter without the basic human stuff. You're not going to find (much) fluff below, because one of my mottos is "show me the science."

So...here we go!

Contents

Principles Du Jour

  1. Develop skills. Knowledge will come.
  2. Little habits add up.

The Big Hitters

If I had to choose just three of the books/articles/etc below, what would they be?

Rapid Learning - 9 Articles Reviewed
I feel funny promoting my own work, but I think this blog post I wrote is a solid resource on how to learn.

Drive: The Surprising Truth About What Motivates Us
Daniel Pink delivers one of the most important books I've read on motivation.

Getting Things Done [Book Summary ]
If this summary isn't clear enough, find another one. There are lots out there. I don't think you need to buy the book, but it's easy to find used. In my view, Allen's crucial messages are:

  1. Get everything you want to do out of your head and into a system you trust.
  2. The purpose of a personal productivity system is to reduce stress.

Randy Pausch, The Last Lecture: Achieving Your Childhood Dreams - YouTube
I know this is four things. But really, watch this. It's over an hour, and completely worth it. Dr Pausch was diagnosed with terminal pancreatic cancer. He delivers a heartfelt talk that would shame any "motivational speaker," because he's not motivated by fame or money since he, at the time, had only a few months to live.

Learning

Fufillment

Productivity

Business

Business Plans
In my meeting, I was asked about business plans. I have limited experience writing a business plan, and I knew there'd be plenty of resources available online, such as those listed.

Here's my opinion: unless you're seeking investors or a loan, the point of working on a business plan is to get you thinking, and to prepare for conversations with other professionals. This quote sums that up nicely.

"In preparing for battle I have always found that plans are useless, but planning is indispensable." --Dwight D. Eisenhower

Communication and Presentation

Despite not listing any resources below, communication and presentation might be the most important area any person can work on.

  • Interpersonal (Toastmasters, acting, practice presentations and record them).
  • Simple courtesies: thank-you notes, formalities, emails.
  • Follow through. Under-promise, over-deliver.

Programming-Specific

Developing a software engineer curriculum is hard, because there are about twenty subject areas. Start with what interests you, the rest will follow. See Appendix B for an overwhelming list of what it can take to write a single, professional web application.

  • Learn about the fundamentals of programming and what's physically happening in the computer. A lower-level language like C++ helps with this, but don't learn the language, just the concepts. A partial list: what are...
    • Memory addresses
    • Arrays
    • Collections (such as linked lists and dictionaries)
    • Sorting
    • Loops
    • Iterating and Enumerating
    • Objects
  • Manifesto for Agile Software Development
  • Principles Behind the Agile Manifesto
  • Fundamentals of Scrum/Kanban/Lean. Try one (I like Kanban).
  • Accelerate: The Science of Lean Software and DevOps <= One of the most important books on development practices today
  • Podcast: Developer Tea <= Ten minute programs about improvement. I love this show.
  • Find the [your-language/platform-here] version of Morning Dew - Daily links for Windows and .NET developers.
  • Automate repetitive tasks
  • Systematize administrative routines (tasks, calendar) (plain text is great). That is, make it easy to practice GTD or whatever method you choose.
  • Tools are an aid, not an end. Learn your tools, but don't become a tool junkie.
  • Be ruthless about maintainability (and maintenance)

Appendix A - Skills (I Think) Software Developers Need to Cultivate

Sorry, I know I'm all about evidence, but I haven't researched this. Here is my opinion on skills/traits specific to software development.

  • Puzzle/problem solving. Programmers have to be able to solve problems. In my opinion, the very best are interested in how to solve problems multiple ways, and never think they have the only right answer.
  • Tenacity. Programmers are faced with tasks that take hours, days, or months to accomplish. They face problems that often don't have obvious or simple answers. They have to keep after it. And they're sitting in a chair, which is completely unhealthy.
  • Abstract thinking. This is a fact, because software is an abstraction. Programming is one of the few fields where what you see is not what you get. Developers stare at words that are instructions later interpreted to produce something someone sees. It's not natural or easy. Imagine your job was to describe, in braille, how to write an English document that explained all the steps to painting Van Gogh's Starry Night, and if the painting doesn't look right the braille book doesn't open.
  • Communicating complexity simply. On a scale of 1 to 10, most programmers reach about a 2 on this. A program is like a night at the theater (or movie, or symphony). You, the audience (manager, user) have no idea what it took to create. It looks simple, it must have been. Developers, especially seniors, must be able to explain how something seemingly simple will work, and why it will take a year to do it.
  • Understand everyone else's job. Scale of 1 to 10: most programmers are a 3 (but think they're a 7). This really depends on what area of software you're working on, but it's rare for programmers to work on software they use. A consulting shop will work for all kinds of clients. In addition to the gobs of information about their own jobs, programmers often need to understand essentials of diverse fields. I, for example, have needed to rapidly learn about: accounting, manufacturing, aircraft maintenance, and radio-nucleotide decay, to name a few.
  • Research. Programmers need to be able to figure out how to query the internet for information, then they have to evaluate the dozen different answers and determine which, if any, fit the issue at hand. I spend as much time researching as I programming.

Appendix B - Everything You Might Need to Know To Create an Enterprise-Level Web Application

Don't worry, I promise, you'll get there. And most of the time, you'll work with other people who know the stuff you don't.

User Interface

  • IDEs: Visual Studio, Visual Studio Code, text editor(s),
  • Design Prototyping: Balsamiq
  • Design Images: Photoshop/GIMP/Paint.Net, Illustrator/Inkscape
  • Image Formats: JPG, PNG, GIF, SVG
  • HTML
  • CSS
  • CSS Extenders (Less, Sass, CoffeeScript)
  • Dynamic web page languages and templates: WebForms, Razor forms,
  • Javascript language
  • Javascript frameworks: JQuery, Angular, Backbone
  • Javascript style checking: ESLint
  • Javascript Unit Testing: Jasmine, Karma, Angular-mocks
  • Package Managers: NPM
  • Integration Testing: Selenium
  • Authentication: OAuth, OpenID
  • Security: CORS, Cross-site injection
  • Performance
  • Other tools: Chrome F12, Fiddler
  • Concepts: page layout, colors, user experience, accessibility (handicapped), minification, HTTP protocol, MVVM, MVC (specifically views), REST, mocking, dependency injection

Web Service

  • IDEs: Visual Studio, text editor(s), difference editors (Beyond Compare, UltraCompare)
  • Languages: C#, VB.Net
  • HTTP
  • REST
  • WebAPI
  • SOAP
  • MVC (specifically models and controllers)
  • Pipelining: OWIN
  • Package Managers: NPM, NuGet
  • Unit Testing: MSTest, xUnit, NSubstitute
  • Dependency Injection/Inversion of Control: Ninject, Simple Injector
  • Authentication: OAuth, OpenID
  • Security: Cross-site injection, SQL Injection,
  • Performance
  • Other tools: Fiddler, PowerShell
  • Logging: NLog, Elastic Search,
  • Concepts: networking, routing, architecture (onion, service/data layers), view models

Web Server Back End

  • IDEs: Visual Studio, text editor(s), diff editors (Beyond Compare, UltraCompare)
  • Languages: C#, VB.NET
  • HTTP
  • MVC (specifically models and controllers)
  • ORM: Entity Framework, NHibernate, Active Record
  • Architecture (layers, onion,...)
  • Web Servers: IIS, Apache, Node.js
  • Pipelining: OWIN
  • Package Managers: NPM, NuGet
  • Unit Testing: MSTest, xUnit, NSubstitute
  • Dependency Injection/Inversion of Control: Ninject, Simple Injector
  • Authentication: OAuth, OpenID
  • Security: Cross-site injection, SQL Injection,
  • Performance
  • Logging: NLog, Elastic Search,
  • Other tools: PowerShell
  • Concepts: networking, routing, data modeling, business entity modeling, business rules, test-driven development, REST, mocking, dependency injection

Data Persistence

  • IDEs: SQL Server Management Studio, LINQPad, text editor(s)
  • Languages: T-SQL, LINQ,
  • Databases: SQL (Microsoft, Oracle) No-SQL (MongoDB, Redis)
  • ORM: Entity Framework, NHibernate, Active Record
  • Authentication (network)
  • Security
  • Performance
  • Other tools: Redgate, PowerShell
  • Concepts: database design, data modeling, relational design

Version Control

  • Source control systems: Git, TFVC, Subversion
  • IDEs: command line, SourceTree, Visual Studio extensions
  • Other tools: GitHub, BitBucket, GitLab

Methodology

  • Development Approaches: Waterfall, Agile
  • Agile methodologies: Scrum, Kanban, Lean, eXtreme Programming
  • Project/Task Management: Kanban/Scrub board, TFS,
  • Issue Tracking: TFS, FogBugz, Jira, Bugzilla, Trac, GitHub, GitLab, BitBucket
  • Architecture Approaches: N-Tier, Domain-Driven Design, Onion
  • Continuous Integration/Release: Jenkins, TFS, TeamCity
  • Concepts: organization, teamwork, communication, creativity, problem-solving, estimating

Testing

  • Unit: Javascript, web, back-end, mocking, automated
  • Integration
  • Acceptance

Platforms

  • Cloud Hosting: Azure, AWS
  • Docker

Miscellaneous

  • Microsoft Office (Word, Excel, PowerPoint)
  • Email
  • Stack Overflow web site for researching problems

Shortest User Story Intro Ever

Examples

The template: As a [who/role], I want [what] so that [why]

The "why" is optional, but often useful.

As a Manager, I want to create employee schedules

As an Employee, I want to see everyone's schedules so I can arrange shift swaps

As an Analyst, I need to be able to view people's timesheet data in various ways so that I can better understand where work bottlenecks come from

Why They Work

  • They're written by stakeholders, typically users.
  • They quickly capture what users want, in their own words.
  • They aren't a feature specification. They are the beginning of a discussion.
  • If it's important enough for you (the user) to want, it's important enough for you to add a story

What If It's a Big Idea?

User stories often start as big ideas (epics). After discussion, they'll get split into smaller stories that can be better estimated and worked on.

Three Steps in a User Story

  1. Write the initial story (the value)
  2. Discuss the story and capture the discussion
  3. Determine acceptance criteria as needed

A user story is done when its acceptance criteria is met.

Example

Value (or Title) As a Manager, I want to create employee schedules

Discussion

  • What's involved in this?
  • How would it be done on paper?
  • How is it being done today?

A schedule includes employee name, id, date, from time, and to time.

[mm] I've found that the handwritten schedules end up being changed a lot due to employees swapping shifts, or being sick. All those changes make the schedule hard to read. So, it'd be great to easily reprint the schedule.

[hg] It sounds like how to print or display schedules should be a new story. What if we used kiosks instead of paper? Or maybe an app employees could view on their phones.

[ss] There needs to be control over who can change my schedules.

Acceptance Criteria
Initially, the scheduler system should:

  • Show an entire week
  • Add employee to a day and shift
  • Show employee total hours
  • Allow easy changing of who's working a shift
  • Allow easy swapping of employee shifts
  • Print a schedule

More Reading

   Older