Current
- Team Topologies (Pais, Skelton)
- Accelerate (Forsgren, Humble, Kim)
- Accelerate: Focus on capabilities, not maturity (models) (Capability models focus on outcomes)
- Measuring Performance:
- Flawed productivity measures: LOC, Velocity, Utilization
- Delivery performance metrics: Delivery leadtime, deploy freq., time to restore svc. (MTTR), chg. fail rate
- Leadtime: comprises ‘fuzzy front end’ and ‘product delivery leadtime’, the latter the more useful measure
- Batch size may be measured via deploy freq.
- Measuring and changing Culture:
- Culture levels: Basic assumptions, Values, Artifacts
- Westrum model: Pathological / Bureaucratic / Generative
- Team dynamics (interactions) matter more than individuals, per a google study
- Shook: “.. not to first change how ppl, think, instead… start… changing how ppl behave”
- Technical Practices:
- Key outcomes: Teams can deploy to prod on-demand, Fast feedback available to everyone and acting on this feedback is prioritized
- Proxy variables for quality: Quality and perf., as perceived by those working on them; % time spent on rework or unplanned work; % time spent on defects reported by end-users
- Developers primarily create and maintain acceptance tests, and they can easily repro and fix on their workstations. This forces more testable designs and more caring about the tests
- Testers perform manual testing incl. Exploratory, usability, acceptance, and working with devs to create and evolve automated suites
- Test data must be acquirable on-demand
- Trunk-based dev works better, except for highly distributed OSS teams where gitflow-based approach can be better
- Architecture:
- Key architectural trait is loose-coupling (a service can be changed and validated independently of other services (and not requiring integration-testing with them)
- Two common traits to high-performing teams: Testability: Can do most testing without an integrated env.; Deployability: Can deploy / release services independently of others
- High-scoring architectural capability teams have minimal comms req’d between teams to get work done, and architecture facilitates ability to change, test and deploy independently from other teams (arch and teams are loosely coupled). This in turn requires each team be cross-functional
- “Conways law”: Orgs are constrained to produce designs which are copies of the comm structures of those orgs
- “Inverse Conway maneuver”: Evolve teams and org structure to support ability of teams to get their work done without high-bandwidth comms between teams
- Loosely-coupled arch enables scaling the org
- Teams should be allowed to choose their tools… but there is a place for standardization, particularly related to infrastructure
- Amazon quote: “Debugging probs with someone else’s code gets a lot harder… unless there is a universal standard way to run every service in a debuggable sandbox”
- Architects should focus on engineers and outcomes, not tools and technologies: Architects should collaborate closely with the engineers using tools to help them achieve better outcomes and provide the tools and technologies to enable those outcomes
- Integrating InfoSec into the delivery lifecycle:
- Infosec: ensure there are easy-to-consume, pre-approved libs, pkgs, toolchains, and processes available for devs and ops – giving devs the means to build security in, rather than sec teams doing security reviews themselves – involve infosec throughout dev lifecycle
- Rugged DevOps: Recognize unintended use, attacks, and responsibility to be rugged
- Management Practices for Software:
- Lean mgmt practices: Limit WIP; Visible displays showing key quality and productivity metrics, and current status of work (incl. defects), aligning these metrics with operational goals; Using data from APM and other monitoring tools to make decisions on a daily basis
- WIP: Not just asking teams if they are limiting WIP and have processes in place to do so; important to make obstacles to higher flow visible – WIP limits are no good if they don’t lead to process improvement that increases flow
- CABs not only slow things down, but also do not improve stability. Recommendation: Use lightweight peer-review process
- 2 mechanisms that work well for auditors: Independent approval of a change (e.g., commit) by a peer in a system of record (like github); Changes applied to prod only using a fully automated pipeline – auditors have a complete record of what changes were done vis version ctl., what tests and validations were run, who approved them and when
- Product Development:
- Lean prod dev practices: small batches (incl. MVPs); whether teams understand flow of work from biz -> tech teams, and have visibility into it incl. Status; whether orgs seek feedback and incorporate it into prod dev; whether dev teams have authority to create and change specs w/o requiring approval
- Making work sustainable:
- “Deployment Pain” – the level of fear and anxiety pushing code into prod
- Barriers that hide the work of deployment from developers are rarely good, because they isolate devs from downstream consequences of their work
- “Burnout can be prevented or reversed, and DevOps can help”
- Employee Satisfaction, Identity, and Engagement:
- “When employees see the connection between the work they do and its positive impact on customers, they identify more strongly with the company’s purpose, which better software delivery and organizational performance”
- “… sense of identity can help reduce burnout by aligning personal and organizational values”
- “… good devops technical practices predict job satisfaction”
- “… plenty of research linking the presence of women in leadership positions to higher financial performance…”
- Leaders and Managers:
- Transformational Leaders: Vision, Inspirational Communication, Intellectual Stimulation, Supportive Leadership, Personal Recognition
- Servant leaders (followers’ development and performance) and Transformational leaders (getting followers to identify with the org and engage in support of org objectives) differ in the leader’s focus
- Leaders alone cannot achieve high DevOps outcomes
- Enable cross-functional collaboration by: Building trust with counterparts on other teams; Encouraging practitioners to move between departments; Actively seeking, encouraging and rewarding work that facilitates collaboration
Recent
- Lean Analytics: Use Data to Build a Better Startup Faster (Croll, Yoskovitz)
- “What is a Concierge MVP? A concierge approach in which you run things behind the scenes for the first few customers lets you check whether the need is real; it also helps you understand which things people really use and refine your process before writing a line of code or hiring a single employee.”
- “Lean, analytical thinking is about asking the right questions, and focusing on the one key metric that will produce the change you’re after.”
- What Makes a Good Metric? Comparative; Understandable; Is a ratio or a rate; Changes the way you behave
- Five things to keep in mind choosing the right metric: Qualitative vs. quantitative; Vanity vs. actionable; Exploratory vs. reporting; Leading vs. lagging; Correlated vs. causal
- KPIs
- Pirate Metrics
- Eric Ries’s Engines of Growth: Sticky engine; Virality; Payment
- Ash Maurya’s Lean Canvas
- The Stages of Lean Analyics
- One Metric that Matters (OMTM)
- “Capture everything, but focus on what’s important”
- “Every team reports to the entire company weekly on KPIs, movement and summaries… having company-wide transparency into the metrics keeps us all informed”
- “By stripping our daily KPI reporting down to just a few metrics, it’s clear what we’re focused on as a company and how we’re doing”
- Business growth comes from improving one of these five “knobs”: More stuff; More people; More often; More money; More efficiently
- My Evolution as an Entrepreneur: The story of Blackwell Consulting (Blackwell)
- Applying lessons learned at a big company, IBM, to starting a new one (Blackwell Consulting)
- Lessons are also applicable to innovating within a large organization, offers a “road map for getting this done in a bureaucracy”
- Emphasizes the importance of perseverence and effort
- Colloquial writing style makes this a rewarding read
- The emphasis on the importance of building relationships applies not just to sales but other roles as well
- The summary “Getting Smarter and More Successful” sections at the end of each chapter are excellent
- Lean Enterprise: Adopting Continuous Delivery, DevOps and Lean Startup at Scale (Humble, Molesky, O’Reilly)
- Excellent treatment of Lean as applied to Software Delivery – tying together Lean Development, Lean Operations, Lean Analytics, Lean UX and Lean Startup concepts
- Deployment Pipeline is a heavy focus area, building on Humble’s earlier book Continuous Delivery (whose Deployment Pipeline chapter is free online)
- Other key themes:
- The ability to utilize Self-service test environment provisioning to stand up test environments on demand (using a public cloud service if need be) is crucial to quickly run long-running tests via parallelization and avoid shared resource bottlenecks between projects
- The Kanban method is the best approach for incremental, evolutionary improvement on an individual project basis – references the Anderson Kanban book below
- “Actionable Metrics” and “One Metric That Matters” are much more effective than “Vanity metrics” to provide useful feedback on a project or process improvement initiative
- GRC (Governance, Risk and Compliance) prevention-style enforcement (such as for PCI) should be balanced with the need for development teams to move quickly
- A Product-oriented approach is more effective for both new product development and any custom software development than is a Project paradigm in delivering customer value
- Innovation in process improvement works in much the same way as that for new product development, including Crossing the Chasm from Early Adopters to the Early Majority
- Continuous Process Improvement should occur continuously during feature development and maintenance work, not as a separately scheduled initiative
- BDD in Action: Behavior-Driven Development for the whole software lifecycle (Smart)
- Author is primary contributor to Serenity-BDD reporting framework
- Overview of BDD approach and various tools, languages
- Kanban: Successful Evolutionary Change for your Technology Business (Anderson)
- Case-study based description of how to apply Kanban approach to software project management
- Includes a section comparing / contrasting to Goldblatt’s Theory of Constraints
- Lays out the essentials of Kanban (as it applies to software projects) better than I’ve seen anywhere else
- Describes a classification approach called “Class Of Service” I’ve seen only here, such as for distinguishing between Urgent / Date-driven / ImportantNotUrgent / Slack items, using Kanban WIP limits to manage each class
- Good section on SLAs – basis for how well the process is working from a delivery standpoint
- Good section on metrics and reporting, how to best use Kanban tools like the Cumulative Flow Diagram and metrics like Cycle / Lead time
- The Art of Unit Testing: With Examples in .NET (Osherove)
- Very readable, pragmatic writing style
- Includes not just DI info, but how to name and organize test bodies, etc.
- Other topics include Fakes (umbrella term for Mocks and Stubs), Integration vs. Unit, Isolation frameworks compared
- CLR via C#: 4th Edition (Richter)
- Excellent reference for the CLR specifically and C# by example
- Some of the most valuable topics: Delegates, Exception handling, Heap and GC, Threads, Async ops, Sync constructs
- ThinkStats: Probability and Statistics for Programmers
- Examples in Python
- Dependency Injection with Unity (Betts / Melnik et al.)
- Great intro to using MSFT Unity Framework
- Many examples in the context of real apps
- Topics include Dependency Injection, Interception
26thcentury 