Articles on matt2ology Tech Journal and Blog

Highlights of Jeffrey Kaplan - Lecture #9: How to Read So That You Retain Information

Tue, 31 Mar 2026 00:00:00 +0000

Lecture #9: How to Read So That You Retain Information

Source published date: 2021-08-17

Source link: Lecture #9: How to Read so that you Retain Information by Jeffrey Kaplan

Literature note: jeffrey kaplan lecture 9 how to read so that you retain information

Introduction

Engagement Over Consumption

Cite

force yourself to interact with the semantic content of what you’re reading. - View Highlight

Marginalia / Reflection: Engage with the material

Thinking Through the Text

Cite

have a procedure that forces you to think through the ideas contained in the text. - View Highlight

Marginalia / Reflection: Abstract the key points and ideas.

Marginalia: Capture Thoughts In Context

Cite

The procedure that I’m going to recommend in this video is a version of marginalia. - View Highlight

Marginalia / Reflection: Jeffrey Kaplan recommends the practice of taking notes along the margins of the printed text. Providing context and locality of your notes, summarizations, questions, and reflections.

Muscle Memory

Analytical Reading Practice

Cite

if you want to stand a chance of remembering that text, what you want to do is you want to read with focus and thought. You want to be thinking through the ideas, mulling them around in your mind right as you’re going through. - View Highlight

Marginalia / Reflection: Be an active, mindful, reader. Not to read to absorb, but to read while applying critique and analysis of current text and previous arguments made from the author.

Micro-Summarization Method

Cite

Here’s what you do: you read the first paragraph of the reading. You read that paragraph, and in the margin, you summarize that whole paragraph in one sentence. - View Highlight

Marginalia / Reflection: The Jeffrey Kaplan’s reading procedure:

Step 1) Read the first paragraph of the reading.
Step 2) In the margin summarize that whole paragraph in 1 sentence.

How to Read

Compression Requires Understanding

Cite

It’s important that you summarize right. So if this paragraph is six sentences long, you can’t just write six sentences in the margin; that won’t work because copying over text you can do that without really thinking about what it means. But summary — you can only summarize something. You can only take six sentences’ worth of ideas and condense them down into one sentence of ideas. You can only do that if you understand what those six sentences mean and figure out what the central core idea is that all of those six sentences have in common. So it has to be a summary; you write a one-sentence summary in the margin. - View Highlight

Marginalia / Reflection: Don’t transcribe, don’t just rephrase, the paragraph. Extract key ideas/takeaways. You’ll loose some resolution, but the goal is to condense and summarize the multiple points articulated.

Build Understanding Incrementally

Cite

Then you move on to the second paragraph. You read that paragraph, and for that paragraph also, you write one sentence of summary in the margin. - View Highlight

Marginalia / Reflection:

Step 3) Read the 2nd Paragraph and write a 1 sentence summary of the 2nd paragraph you read

Contextualizing New Information

Cite

Then you get to the third paragraph, and this is where things get interesting. When you read the third paragraph of the text, you’re going to write two sentences in the margin. The first sentence in the margin next to the third paragraph is not going to have anything to do with the third paragraph. This sentence is going to summarize the first and second paragraphs. - View Highlight

Marginalia / Reflection:

Step 4) After reading the 3rd paragraph two sentences are written in the margins: 1 - a sentence connecting ideas and summaries leading up to the current point (summaries of paragraph 1 & 2); and, 2 - a sentence about the 3rd paragraph you’ve just read.

Expanding the Summary Chain - Never Start Fresh Carry Forward

Cite

then we move on to the fourth paragraph. The fourth paragraph also gets two sentences in the margin. The first sentence in the margin next to the fourth paragraph summarizes everything the previous paragraphs, one, two, and three, and then the next one just summarizes paragraph four. Then you keep going. - View Highlight

Marginalia / Reflection: From the 3rd paragraph on every paragraph gets two sentences summaries: the first sentence connects summaries prior to the current paragraph; and, the second sentence recaps the current (n-th) paragraph.

Distilling the Big Idea

Cite

one sentence that summarizes everything that came before. You condense it all down into just one sentence. You’re going to leave things out, of course. You have to, because now you’re condensing many paragraphs into just one sentence. So, you’re going to have to leave a lot of stuff out. You’re going to have to make a decision. You have to think through what’s the most important thing that all of these paragraphs have in common or that connects them, or that they’re getting across: one sentence for everything previously, and one sentence for that last new paragraph. - View Highlight

Marginalia / Reflection: From the 3rd paragraph on the first sentence gets updated encapsulating or highlighting the most important elements or what connects each summary.

id1002157868

Cite

what a waste of time is? Sitting and passing your eyes over the text and not retaining it, not thinking through it and absorbing it, that’s a waste of time; that’s inefficient. - View Highlight

id1002157948

Cite

There is no way to summarize a text like this without thinking through the material and understanding it and retaining it. I want to emphasize this point again: taking notes in the margin in this way where you summarize what’s going on actually saves time. - View Highlight

Efficiency

id1002158787

Cite

I’m medium-level smart, but I show up to everything having thought through the material, right, and retaining it - View Highlight

Active Learning in Action

Cite

On the first day of lecture, the professor asked, “What is economics?” There was silence in the room for a long time. Then, I raised my hand and said, “It’s the study of the allocation of scarce resources.” The professor said, “Correct,” and then just moved on to the rest of the material. - View Highlight

Marginalia / Reflection: Actively engaging with the material improves memory recall.

What is Economics

id1002164751

Cite

if you think through the ideas, the powers of retention of memory that you will gain, will be incredible. - View Highlight

id1002167290

Cite

Speed reading is a scam. - View Highlight

Bonus Rant

id1002179478

Cite

is this a prank? Are you kidding me? The order of the words in sentences matters to the meaning of those words. You need to read all the words in order; or else you’re not going to understand what those words mean. - View Highlight

id1002179558

Cite

“Professor Kaplan, you’re not being fair; that’s just one thing that one person said.” But you should test speed reading by its most sophisticated methods, such as the well-known technique of rapid serial visual presentation. - View Highlight

id1002179599

Cite

First of all, just because you give something some fancy label doesn’t mean it’s a Real things - View Highlight

id1002179727

Cite

The results every single time show that speed reading works like skimming, which is to say, it doesn’t work. - View Highlight

Pop Quiz

id1002180218

Cite

definition of economics up on the board; I never wrote it up. I just said it a few times. - View Highlight

id1002180298

Cite

I made you think through it. - View Highlight

id1002180330

Cite

I like walked through a thought process involving this definition of economics. Remember the whole thing about sand and I got the B-roll photo of sand and sand as a scarce resource that’s thinking through the definition of economics. - View Highlight

Thoughtful Reading = Lasting Memory

Cite

If you have to think through what something means, then you absorb it and you remember it. - View Highlight

Marginalia / Reflection: Think while reading, so you can learn it and remember it with context.

Highlights of UnityCoin - Clean Code - Uncle Bob / Lesson 6 - Agile

Sun, 19 Oct 2025 00:00:00 +0000

Clean Code - Uncle Bob / Lesson 6 (Highlights)

Source published date: 2019-08-09

Source link: Clean Code - Uncle Bob / Lesson 6

Literature note: UnityCoin - Clean Code - Uncle Bob / Lesson 6 - Agile Solutions for Balancing Deadlines and Software Quality

Highlights

How do you manage a software project?

Managing software projects is inherently difficult because it forces a confrontation with the “Iron Cross” of project management, the fundamental constraint that you can never simultaneously fix quality, speed, cost, and scope. While traditional mismanagement often relies on “hope and prayer” or 80-hour workweeks to meet impossible demands, the various implementations of Agile, such as Scrum or Extreme Programming (XP), offer a data-driven alternative. Instead of dictating unachievable goals, effective management involves using frequent feedback loops and short iteration cycles to constantly adjust these “control knobs.” This iterative approach ensures that the project is steered toward the best possible outcome based on reality rather than original, often flawed, assumptions.

Variations of Agile Methodology

What kind of agile is it? Is this scrum, or scrum but, or scrum fall, or XP? So, do you do XP? XP, stream programming. - (View Highlight)

Reflection:

There are many implementations of Agile.

Reflections on Software Project Management Challenges

How do you manage a software project? - (View Highlight)

Reflection:

Badly?
Hope and prayer?
With Great Difficulty
Dictate and Motivate: dictate - if we don’t succeed, we let “them” win; and, motivate “hang in there”.

The High Cost of Project Mismanagement

The reason that we need to have a way to manage software projects is that mismanagement has some severe costs. - (View Highlight)

Reflection:

Leads to:

Producing the wrong product
Producing a product of inferior quality
Being late
Working 80 hour weeks

The Iron Cross: The Fundamental Constraint

why is it so hard to manage software projects? What is the fundamental cause of this? The answer to that has been known for a very long time, and it’s actually a very simple problem: good, fast, cheap — pick any three; you’re not going to get the fourth. This is called the iron cross of project management. - (View Highlight)

Iterative Adjustment: The Power of Feedback Loops

how to adjust the knobs: how good, how fast, how cheap, how done. A good manager will do that by adjusting the knobs with lots of feedback to drive the project to the best possible outcome. That outcome may not be what was originally targeted. - (View Highlight)

Reflection:

Lots of feedback - increase iteration cycles (2 weeks most common). Agile is to have multiple short iterations, so to be best informed by having more meaningful communication to help drive the product to what the customer wants without guessing what they want.

Finding the optimum solution - Data

Successful project outcomes are driven by empirical data rather than blind optimism, utilizing tools like velocity and burndown charts to provide a “10-second status” on real-world progress. This radical transparency acts as a diagnostic tool that “destroys hope” to surface the actual reality of a project, allowing managers to address complexity spikes and “estimate drift” as soon as they occur. By treating requirements as fluid and estimates as non-binding forecasts, teams can maintain alignment through shared visibility of the next major deliverable. Ultimately, the goal of these “information radiators” is to ensure everyone, from developers to stakeholders, understands the true health of the project, enabling the proactive management necessary to navigate the inherent chaos of software development.

Data-Driven Optimization for Successful Outcomes

to drive a project to a successful outcome, to the best possible outcome, what you need is data. - (View Highlight)

Reflection:

Finding the optimum solution

We need to manage the project to the best possible outcome
An outcome that maximizes all four qualities: good (quality), fast (schedule), cheap (cost), done/scope (the deliverable).
To do this, we need: DATA!

Velocity: The Predictive Power of Weekly Data

what kind of data do we need? Wouldn’t this be great? This is a chart on the wall, and the chart shows how much got done every week. - (View Highlight)

Reflection:

Velocity chart. This enables managers to predict the volume of work that can be done within a week.

Visualizing the Path to Completion: The Burndown Chart

another piece of data that would be really useful, that’s a burn down chart. A burn down chart says there’s 400, and by 500, isn’t it about 500 points remaining until the next major deliverable - (View Highlight)

Reflection:

One would hope that volume of work would decrement by the average of team’s velocity.

Embracing Change: Why Requirements Must Remain Fluid

It’s software; remember, first we want the requirements to change. Any software team that freezes the requirements is making a terrible mistake. - (View Highlight)

Reflection:

This puts process in-front of getting what the customer/end-user requests.

Responsive Requirements: Empowering Customer Evolution

We don’t want the requirements to freeze; we want the customers to change the requirements as soon as they know that the requirements need to change. - (View Highlight)

Accurate Forecasting: Handling “Estimate Drift” and Complexity Spikes

But the other possible reason that that bar’s a little bit higher is that the developers looked at the project again They’ve been wrong, and so they rested, which is perfectly acceptable because their estimates are not promises, and therefore we want to know as soon as the developers realize that, you know, our original estimates for Ignite were a little optimistic. We want to know that as soon as possible, so everybody understands what’s happening with this project. - (View Highlight)

Reflection:

On the topic of burndown charts (story points left in sprint/release) we generally want to see the number of story points decrease; however, there may be a case where one would see a spike in story points. This may be a point in that an evaluation of an user story was lower than what the work required actually was (i.e. it was more complexed than they originally estimated).

Estimates vs. Promises: The Value of Early Course Correction

estimates are not promises, and therefore we want to know as soon as the developers realize that, you know, our original estimates for Ignite were a little optimistic. We want to know that as soon as possible, so everybody understands what’s happening with this project. - (View Highlight)

The 10-Second Status: Velocity and Burndown in Action

Put these two charts on the wall. Anybody can walk into the room where those two charts are, look at those charts for 10 seconds and say, “Huh, this team’s getting about 45 points a week done. I think they’re gonna be done in May. - (View Highlight)

Reflection:

Velocity chart and burn-down chart

Radical Transparency: Visualizing Project Health (or Risk)

don’t have those charts on the wall,you are not producing the data that the managers need to know how screwed they are. - (View Highlight)

The Purpose of Agile: Destroying Hope to Surface Reality

The purpose of Agile is to destroy hope. - (View Highlight)

Reflection:

HA!

Agile: A Diagnostic Tool, Not an Accelerator

The purpose of Agile is to destroy hope. Some people say, “You know, we’re doing Agile so we can go fast.” Agile does It does not make you go fast, and it doesn’t slow you down either; it doesn’t change a thing about how fast you go. Agile is just a way to produce data, so that you know just how messed up things are. Then you can manage. - (View Highlight)

Reflection:

Data driven management.

Early Detection: The Prerequisite for Effective Management

We want to know as soon as possible how messed up we are so that we can manage. Because there’s this thing that managers do; it’s called managing. We want to be able to manage the project to a good outcome. - (View Highlight)

Alignment Through Shared Visibility: The 4-Month Look Ahead

the burn down chart, which tells us the number of points until the next major deliverable. - (View Highlight)

Reflection:

All work has been planned to the next major deliverable. It isn’t management saying just do the work it’s the whole team on same level understanding what is going on. This is done every iteration - curate another 3 to 4 months look ahead.

Radical Visibility: The “Information Radiator”

The purpose of agile is to get these two charts on the wall. If you don’t have these two charts on the wall, you are not doing agile; you’re doing something else. Now, the charts have to be on the wall. Could they be in somebody’s spreadsheet somewhere? It’s better to have them on the wall because then everybody can see them, and everybody can know how screwed they are. - (View Highlight)

Reflection:

Velocity chart and burn-down chart

What is the first thing know about project - The Management Paradox

Project management begins with the deadline, the only truly fixed point, which necessitates a fluid approach to scope where features are prioritized and replanned rather than treated as rigid requirements. Because customers often cannot articulate what they truly need until they see what they don’t want, Agile utilizes iterative “show-and-tell” cycles to align the product with evolving expectations. This stands in contrast to the Waterfall model, where treating analysis and design as “finished” deliverables often leads to “process inflation” or “tacking” hacks into the code as reality shifts. By starting with an “Iteration Zero” to gather high-level user stories, teams treat documentation as a placeholder for ongoing conversation rather than a static contract, allowing the software’s inherent malleability to drive the project toward a successful outcome within the constraints of the fixed delivery date.

The Deadline: The Starting Point of Every Project

The date. - (View Highlight)

Reflection:

The first thing you know about any project, even before the name of it, is the date. When is the deliverable date?

The Fixed Date vs. Fluid Scope

the date is frozen. There’s no point arguing about the date; it’s a hard business date. The requirements are not the requirements. - (View Highlight)

Reflection:

If every feature is important than none of them are. Core features of each major release can be replanned or deprioritized, and can later be incorporated in the next iteration.

Iterative Alignment: The “Show-and-Tell” Strategy

why are they going to change all the time? Well, because the customers don’t really know what they want, and the more we talk about what they want, the better idea they kind of get about what they want. But they really don’t know what they want until they see something execute that is not what they want. - (View Highlight)

Reflection:

Agile is to work in iterations. Ideas get better with iterations. As a result show-and-tell the customers early and often to see if it is in alignment to what they envisioned the end product to be.

The Waterfall Model

The Malleability of Software: Why Agile Fits

The environment of software developers is an environment where dates are fixed, but requirements are not, and somehow we have to drive the project to a good outcome. - (View Highlight)

Reflection:

Software is made to be flexible and dynamic. Major changes can be made relatively quickly. Other engineering disciplines are not susceptible to such rapid changes; for this reason, waterfall methodologies are better suited.

The Foundation of Process: Winston Royce’s Three Phases

Winston Royce, and what he said—he wrote a very famous paper titled “Managing the Development of Large Software Systems,” - (View Highlight)

Reflection:

Break the project up into 3 major phases:

Analysis
Design
Implementation

The Myth of “Finished” Analysis and Design

Analysis and design are not boolean deliverables; they do not have two states: done and not done. They are simply open. - (View Highlight)

Reflection:

Fails in the waterfall model. Analysis and design are constantly evaluated and worked on.

The “Tacking” Trap: Technical Debt in the Making

Writing code. Meanwhile, the requirements are changing, and you’d like to kind of reanalyze them and redesign them, but you don’t really have time for that. So you tack them into the code - (View Highlight)

Iterative Development - Calculate Day

The Trap of Process Inflation: More of What Didn’t Work

Next time, we’re gonna have to do it right; we’ll do more analysis and more design. Now, I call this runaway process inflation. Right? You take the thing that didn’t work and you do a lot more of it. - (View Highlight)

Reflection:

It isn’t about doing more of the analysis or design. Requirements changed, so they “hacked” their way into implementation ignoring the original design documentations.

Iteration Zero: Establishing the Foundation

In that first sprint, that first iteration, the first two weeks, some people call this iteration zero. What we’re doing there is gathering some requirements. Not all of them, because we can’t get them all, but we’ll talk to the customer a little bit. This is when we’re writing use cases or, nowadays, we call them user stories. - (View Highlight)

The Card: A Placeholder for Conversation

a user story is usually just a word or two on a card. You don’t need much; you certainly don’t want a lot of detail yet. Detail comes later, so we just want to kind of have a reminder, a little card that reminds us of what this feature is. - (View Highlight)

The Control Knobs of project mgt

Effective project management relies on the ethical “early warning” provided by Agile’s continuous measurement, allowing teams to adjust the “control knobs” of schedule, staff, and scope before a crisis occurs. While the temptation to turn the “quality knob” is high, the paradox of speed dictates that the only way to go fast is to go well; sacrificing engineering standards merely creates technical debt that slows future progress. Similarly, Brooks’s Law warns that adding staff often backfires by draining the productivity of veteran members, leaving scope, negotiating which features are truly necessary, as the primary lever for hitting deadlines. Ultimately, because software is inherently difficult to estimate, as intuitive human actions are incredibly complex to describe as precise instructions, success depends on a rational environment where developers’ empirical data wins over stakeholder authority, ensuring the project is managed as a series of time-boxed course corrections rather than a fixed, impossible promise.

The Ethics of the “Early Warning”: Using the Control Knobs

early is a good time to tell everybody you’re going to be late. - (View Highlight)

Reflection:

The Control Knobs of project management:

Schedule: Push the date back if the scope is truly “fixed”.
Staff: Add resources (though this often slows things down in the short term).
Quality (⚠️ DON’T TOUCH THIS KNOB ⚠️): A dangerous knob to turn, as lowering quality (less testing, “hacking” it in) creates technical debt that kills future velocity.
Scope: Cut low-priority features to hit the date.

Brooks’s Law: The High Cost of Adding Staff

doubling the staff does not have the effect of doubling the throughput. What really happens is that when you add new people to the project, the old people slow down enormously. The whole schedule begins to slip because the new people suck the life out of the old people. You kind of hope that after a month or two the new people get smart enough to start getting faster, and even if that’s true, it’s risky as hell. Besides that, if you add more people to the project, it’s going to cost more money. - (View Highlight)

The Illusion of the Quality Knob: Going Faster by “Producing Crap”

the quality knob. Everyone knows you can go much faster by producing crap. - (View Highlight)

The Paradox of Speed: “Fast” is a Product of “Well”

you go fast. You go fast by going well. - (View Highlight)

The Negotiation: Scope as the Primary Lever

maybe, some of those requirements that we were planning on didn’t really need to be there by November. Maybe the customer could live without some of those requirements for a while. So let’s talk to the stakeholders about that and see if we can live without some of these requirements. - (View Highlight)

Data vs. Authority: The Rational Project Environment

Although the stakeholders have the moral authority and the pure righteousness, the developers have the data, and if you work in a rational organization, I leave it up to you; if you do, the data must win - (View Highlight)

The 30,000-Foot View: Agile as a Measurement Tool

Just tell us what you want first so that we never, ever deliver something you don’t need. That’s agile. That’s agile. At the 30,000 foot level, agile is a simple technique. You take a project, you subdivide it into time. In time boxes, you measure how much you get done. In those time boxes, you use that measurement to project the end date, and then you manage and manage and manage, because every software project is always a horror scene. - (View Highlight)

The Complexity Gap: Intuition vs. Instruction

Why can’t we estimate software? They can estimate other things; why can’t we estimate software? How long does it take you to tie your shoes? Seconds. How long would it take you to write the instructions to tie your shoes? You can’t even begin to estimate that, can you? - (View Highlight)

Reflection:

Why we can’t estimate software. Things we can do intuitively takes significant time to describe all the steps, edge cases, to a computer that will do exactly as you have described.

Short Cycles - Agile Software Development Practices - Extreme Programming

Agile is fundamentally a data-driven discipline designed to surfaced “bad news” early by breaking work into short cycles, rather than a method for guaranteeing fixed scope, dates, or costs. True success relies on the integration of business-facing Scrum practices with rigorous engineering disciplines; without technical foundations like test-driven development and refactoring, teams fall into “Flaccid Scrum,” where accumulating technical debt causes velocity to grind to a halt. In this framework, velocity serves as a thermometer to measure stable, predictable capacity rather than a performance goal to be increased, as unexplained upward trends often signal artificial pressure or point inflation. Ultimately, Agile is most effective for small, decoupled teams focusing on high-return tasks, where projects conclude not when a checklist is finished, but when stakeholders recognize that the cost of further work exceeds the remaining potential value.

The Iron Cross: The Impossible Promise

estimates promise— it can never be promises, never be promises. You cannot promise to deliver fixed scope by a fixed date with fixed quality and fixed cost. You can’t do that. That’s the Iron Cross. The best way to manage that situation is this: do it in lots of short cycles; get the bad news as early as possible. - (View Highlight)

The Agile Rings: From Business Strategy to Engineering Excellence

Agile is for: to get the bad news as early as possible. It’s not to go fast, just to get The bad news early: the disciplines of Agile are on the screen. - (View Highlight)

Reflection:

The Disciplines of Agile

A process extracted from “Extreme Programming (XP)”

Green outer ring - Scrum - Business-facing practices (does not deal with the internals):

Whole Team
Acceptance Tests
Small Releases
Planning Game

Blue floating in-between the rings - the team practices - how a team behaves:

Continuous Integration
Metaphor
Sustainable Pace
Collective Ownership

Red inner ring - The engineering practices - the programmer-specific practices:

Test Driven Development
Pairing
Simple Design
Refactoring

Scrum without the inner red ring is known as “Flaccid Scrum”: scrum that fails.

The Death Spiral of Flaccid Scrum

what are the symptoms of Flaccid Scrum? Closest scrum starts to work initially just fine. You go through a few Sprints, everything seems to be fine. The team is making good decisions, there’s good communication with the product owners and so on. Everything’s going along fine, and then you start to see the team slow down. Thus, the team gets slower and slower with time. Why does this happen? Because they’re not practicing the engineering practices. In the middle, the engineering practices are the things that keep the architecture and the design and the code clean, and without that, Scrum will slow down and grind to a halt. - (View Highlight)

The Efficiency of Chaos: Scrum as a Mess-Maker

Scrum is a really efficient way of making a mess really fast, unless you augment it with the engineering practices in the middle. - (View Highlight)

Reflection:

Scrum without engineering practices systematically sets the team for failure.

The Planning Game: Managing the Negotiable

the planning game. This is mostly what Scrum is about: the planning game. - (View Highlight)

The Scale Paradox: Agile is for Small Teams

Agile, by the way, is a method for small teams to do small things. Agile is not a technique for big teams to do big things. It is a method for small teams to do small things. - (View Highlight)

Scaling Through Decoupling: The “Team of Teams”

If you want to do big things, you have to use a lot of little small teams, and all the small teams are doing Agile. - (View Highlight)

The Scaling Myth: Rejecting “Agile in the Large”

Agile in the large. I’m not sure there is such a thing as Agile in the small. That’s how Agile was first defined, and it was the goal of Agile to solve the problem with small teams. Can you do Agile in the large? I’m not even sure I know what that means. Can you get many small Agile teams to build something big? Sure, sure, but you have to use Agile to do that at some greater level. No, I don’t think so. - (View Highlight)

Reflection:

Consultant BS to play pretend of a process and charge time coaching a solution for a problem that doesn’t exists.

Coordination vs. “Agile Scaling”: A Historical Perspective

We have known how to get small bunches of teams to work for years. You know, we built pyramids. We went to the moon. - (View Highlight)

The Scope of Agile: Small Teams, Small Things

Agile was just about small software teams doing relatively small things. - (View Highlight)

The Brand vs. The Value: The “Noun” Trap

the name of the product becomes more important than what you’re doing with it. - (View Highlight)

The “Cargo Cult” of Frameworks: Process as a Mask

the name of the product becomes more important than what you’re doing with it. - (View Highlight)

Reflection:

Prioritizing a “process” over impactful, meaningful, work.

The “Noun” Trap: Process as a Performance

“Have you done your Jira’s yet?” That, so that tells me there’s a symptom of a problem somewhere, like maybe the tool has become more important than the function. - (View Highlight)

The Power of Comparison: Why Relative Estimation Wins

relative estimates are better than absolute estimates. Programmers are better at doing relative estimation; everybody is better at doing relative estimation. - (View Highlight)

The Value Exchange: The Core of the Planning Game

This is the process. The stakeholders are drawing from this card, and they’re making a cost-benefit comparison: how much value do they get for the cost? - (View Highlight)

Cost-Effectiveness Analysis (CEA) or value engineering: Hunting for “Low-Hanging Fruit”

Good product owners go through the deck and select the highest value cards that have the lowest cost - (View Highlight)

The ROI Engine: Keeping the Deck Lean

the deck is growing. What’s coming out of the deck? High-value cards, cards that have high value for low cost, high return on investment cards; that’s what’s coming out of the deck. - (View Highlight)

The Law of Diminishing Returns in Product Backlogs

the deck starts to get low in return on investment. The more time goes by, the more the return on investment begins to drop away. - (View Highlight)

The Definition of Done: Value as the Finish Line

Projects are not over when everything’s done; projects are over when there’s nothing else worth doing, and the stakeholders acknowledge, “Yeah, there’s nothing else. - (View Highlight)

Iterations as Data Generators: The “Fail-Proof” Sprint

It’s impossible for an iteration to fail because an iteration’s job is to produce data. Even if you produce nothing, you have produced data. - (View Highlight)

The Canary in the Coal Mine: Zero-Point Iterations

An iteration that delivers no points is good data for the managers because boy, something’s gone wrong. Better deal with it. - (View Highlight)

Velocity as a Thermometer, Not a Gas Pedal

Iterations do not fail; the number of points in the iteration is not a goal. You’re just simply trying to measure how much you can get done in each iteration. - (View Highlight)

The Ideal Velocity: The “Flat Line” of Predictability

Time is slow and steady. Dead flat — we don’t want it to rise, we don’t want it to fall. - (View Highlight)

Reflection:

In Velocity chart we don’t want any surprises. No fluxuation in output - predictable.

The Illusion of “Improving” Velocity

You do not want to see a positive slope on the velocity curve unless you can explain it with something like, “Yeah, we added three people to the team.” Now that would be a reasonable explanation. - (View Highlight)

The “Pressure” Distortion: How Stress Corrupts Data

A positive trend probably means that someone is putting pressure on the team, and pressure on the team is going to shift all the numbers. - (View Highlight)

The Death Spiral: Velocity as a Tech Debt Detector

if the velocity chart is going down sprint by sprint, less and less and less gets done? There’s a mess; somebody’s making a mess. The engineering practices are not being followed: not enough tests, not enough refactoring; design and architecture are beginning to fail. You want to catch that real early. - (View Highlight)

Reflection:

Tech debt

Questions and Answers

Effective project management relies on moving away from “write-only” documentation toward high-impact communication and knowledge transfer. This is achieved by redefining seniority as a mandate for mentorship, where experts utilize constant pairing and the “one page ahead” rule to both teach and solidify their own mastery. To manage technical uncertainty, “spikes” are used as diagnostic stories to buy information and provide accurate estimates for complex tasks. Finally, the success of this system hinges on the Business Analyst, a “bilingual” professional who uses dual empathy to translate customer pain points into actionable requirements while advocating for the technical design needs of the programmers.

The Documentation Graveyard: Compliance vs. Communication

it’s really easy to write a lot of stuff in here, isn’t it? And it’s great because nobody reads it. - (View Highlight)

Seniority as a Teaching Mandate: The True Role of the “Expert”

Mentoring, so mentoring is the responsibility of the most senior people. The more senior you are, the more responsibility you have for mentoring, for teaching people who are younger than you. - (View Highlight)

The Senior as a Catalyst: Pairing as the Primary Duty

The most senior people should probably spend their time pairing with more junior people all the time. - (View Highlight)

The Virtuous Cycle: Learning Through Teaching

You who are senior learn how to teach. By the way, I’ll tell you a little secret: the best way to learn something is to teach it. All you have to do is stay one page ahead; so all you’ve got to do is one page ahead, one day ahead. - (View Highlight)

The Spike: Buying Information to Reduce Uncertainty

a spike is for: to estimate another story. So that’s another way you can do this data analysis thing. You say, “Okay, I need three points just to look at the data to try and imagine how long it’s going to take me to actually analyze it.” - (View Highlight)

Reflection:

A spike is a user story to estimate another user story; for example, estimate how long it will take to get the database working.

Business Analysts “The Bilingual Professional”: Bridging the Gap

Business analysts are one of the hardest jobs there is. To be a business analyst, you must be technically astute enough to talk to programmers, and you have to be personally astute enough to talk to the business side. There are a lot of people that are like that who can turn both directions and communicate well across that boundary. - (View Highlight)

Reflection:

The ability to be technical and sociable to communicate the jargon and situation to non-technical business people.

The Dual Empathy of the Business Analyst

You have to be able to put yourself in the position of the customer and understand what the customer needs so that you can communicate requirements to the software development team. But then you have to be able to put yourself In the programmer’s position, they need to understand what they are fighting against and how they need design. - (View Highlight)