One of the most perplexing discussions I've had in recent times was about CI/CD. I've earned my CI/CD scout badge at this stage in my career, so the confusion caught me off guard. This post briefly sets out what Continuous Integration (CI) and Continuous Delivery (CD) mean and addresses the most common misconceptions in the discussion.

My point isn't just semantic. These terms carry decades of hard-won engineering practice, and when we let their meaning drift or decay, we lose crucial wisdom.

Continuous Integration

Continuous Integration is well named compared to many concepts in our industry. The term "integration" refers to merging your changes into the main branch in version control, and the term "continuous" means you do it often. When Kent Beck popularized the term in Extreme Programming Explained (1999), he set an upper limit of a day. After 26 years of progress, you should expect to be doing it far more frequently than that.

You might understand the concept better if we look at examples that don't fit the definition. If you have code on your machine that's more than a day old, you're not practicing Continuous Integration. If you have a branch that's more than a day old, you're not practicing Continuous Integration. It doesn't matter how often you merge from main into your branch, because main is completely unaware of changes, like yours, that haven't been merged yet. That means you have diverging software versions, and at some point, you have to make them all converge.

Continuous Delivery

Continuous Delivery is an approach focused on delivering all changes to users quickly, safely, and sustainably. You keep your code in a deployable state at all times and reject the idea of separate integration, testing, and hardening phases. There are specific technical practices involved here because you need a deployment pipeline that reduces risk and increases your confidence that the software version works.

At this stage in our industry's history, almost everything involved in answering the question "Is this deployable?" should be automated as part of the deployment pipeline. A decade ago, perhaps, you could reasonably list a few stages that were economically unviable for automation. The scale and pace of modern software delivery mean this is rarely the case now.

The simple test is to ask, "Is the software deployable?" If you can't answer this question every day, you're not doing Continuous Delivery. In their book on Continuous Delivery (2010), Dave Farley and Jez Humble detail the principles and practices that let you answer this question, and the research has increased our confidence that this is what good software delivery looks like.

Misconceptions

Let's turn our attention to where the conversation left the trail.

CI doesn't just mean automated builds

One of the most common sources of confusion is that CI just means automated builds and tests. While it's difficult to practice Continuous Integration without automation, the crucial property of Continuous Integration is that all changes are in a shared mainline, not on developer machines or in long-lived branches. Having more than 3 branches or keeping branches open for more than a day slows delivery throughput and makes the software less stable, as reinforced by long-running research.

There's a human process at the heart of CI: each developer chooses to commit their changes frequently to main. Without people deciding to do this, there is no CI.

CI doesn't allow feature branching

There's a misconception that you can do CI and choose a branching strategy, like feature branches. Any branching strategy that keeps a change out of main for more than a day cannot be called CI. You may still choose to use feature branches despite the drawbacks, but you have to stop calling it Continuous Integration, as you aren't continuously integrating all changes.

CD doesn't mean Continuous Deployment, though it can

CD means "Continuous Delivery". It means your software is deployable at all times, and you can test this daily by asking, "Can we deploy the software?" If you don't have a way to answer the question confidently, you're not doing Continuous Delivery. You may choose to deploy every validated software version automatically, which is Continuous Deployment, or you may need to be more tactical about when you deploy. Either is fine.

For both Continuous Delivery and Continuous Deployment, you need high levels of automation and sufficient risk coverage within that automation so you know you can deploy. Continuous Delivery should mean you can deploy at the press of a button, and Continuous Deployment removes the requirement to press the button.

You can't do CD without CI

Some folks were confident that you can do Continuous Delivery without doing Continuous Integration, but the literature on this is very clear. Farley and Humble explicitly include Continuous Integration as a required practice. There's a whole chapter dedicated to it (p. 55 of Continuous Delivery) that adequately explains how it should work and why it's not optional.

CI/CD isn't vague or open to interpretation

Another claim that came up more than once was that CI/CD is vague, open to interpretation, or lacks the detail on "how" you should apply the approach. This does a disservice to those who conscientiously captured the approach, whether that's Kent Beck describing Continuous Integration in Extreme Programming Explained (1999) or Farley and Humble detailing both Continuous Integration and Continuous Delivery in their book Continuous Delivery (2010).

Resist the diffusion

There is a constant temptation in the tech industry to allow semantic diffusion to erode our progress. When we package up a cartload of wisdom into a term, we have to resist the diffusion that follows when people oversimplify our term, remove crucial parts of the whole, or try to brand something with the label that pushes us backward.

We have a history of giving up on these battles, as we seem to have done with Agile and DevOps. These terms had an important meaning that represented a significant step forward for our industry, and losing our energy in their defense lets the perpetual "Late Majority" and "Laggards" (from Crossing the Chasm) drag us all back into their old ways.

CI and CD deserve better.

A lot of developers are using GitHub Copilot as their day-to-day agent harness. But most of them seem to be unaware that with a GitHub Copilot license comes more than a CLI and Visual Studio (Code) plugins. One thing you get access to are GitHub Copilot Spaces.

GitHub Copilot what? Let me first explain what Spaces are and why they are useful.

Why GitHub Copilot Spaces?

If you've used Copilot Chat for a while, you recognize the pattern: you paste in the same background information for the third time this week. The same coding conventions, the same architecture decisions, the same "no, we don't use that library anymore" context. Close the conversation, and Copilot forgets all of it.

Remark: Part of the answer can be found in building up your CONTEXT.md file and using the GitHub Memory feature but it’s not always the right solution.

That's because source code lives in your repositories, requirements live in issues and pull requests, and team conventions often live nowhere except in one person's memory or buried three pages deep in a Teams chat. Plain Copilot Chat can reason about code, but it has no persistent memory of any of that. You end up re-explaining the same background every time you open a new conversation.

A Space gives that background a name and makes it reusable. You build the context once by providing repos, files, issues, PRs, instructions and every conversation inside that Space is grounded in it automatically. No more copy-pasting the same three paragraphs of context before you can ask your actual question.

Concretely, that unlocks a few things:

• Onboarding: point a new team member at a Space instead of a wiki page nobody kept up to date. They can ask questions and get answers grounded in the real, current codebase.
• Consistency: document a repetitive pattern once (how we add telemetry, how we wire up a new endpoint) and every developer gets the same answer instead of five slightly different ones.
• Less repetition, period: stop re-explaining the same architecture decisions in every chat window you open.
• Reuse beyond chat history: a Space stays put even after your own chat history is long gone, and — for organization-owned Spaces — beyond any single person leaving the team.

Or as stated in the documentation:

GitHub Copilot Spaces enables teams to centralize and democratize organizational knowledge by providing a collaborative environment for storing, searching, and refining process documentation. By connecting your repository as a source, Copilot Spaces can index your documentation and issue templates, making them easily accessible and actionable for all team members. This approach reduces single-person dependency risk, accelerates onboarding, and ensures that project management processes are consistent and repeatable.

Sounds interesting, right?

Creating your first Space

Go to github.com/copilot/spaces and click Create space.

You'll need to decide:

• A name for the space.
• Owner: yourself, or an organization you belong to. Organization-owned Spaces can be shared using GitHub's regular permission model, so a team can collaborate on the same Space.

Click Create Space. You can optionally add a description, it doesn't influence Copilot's answers, it's just there to help colleagues understand what the Space is for.

Remark: if you're on a Business or Enterprise plan, Spaces may need to be enabled as a Copilot feature first. If you don't see the option, check with whoever manages your org's Copilot settings.

Once your Space exists, there are two ingredients that shape how Copilot behaves inside it.

Instructions

Free text describing what Copilot should focus on: its area of expertise, what kind of tasks it should help with, and what it should avoid. Think of this as the system prompt for the Space.

An example straight from the Microsoft Learn path:

## Program process documents

- Stored in `docs/`

### Purpose of this Copilot Space

- Centralize scattered project management knowledge in Copilot Spaces
- Convert tacit team insights into searchable, versioned artifacts
- Give all team members equal access to processes, decisions, and rationale
- Connect a repository as a structured knowledge source
- Extract, refine, and standardize workflows collaboratively
- Feed validated improvements back into living documentation
- Accelerate onboarding and reduce single-person dependency risk
- Enable consistent, repeatable project execution

## Issue templates for program process documents

- Stored in `.github/ISSUE_TEMPLATE/`

Feel free to swap this out for something closer to your own use case.

Sources

This is the actual context. You can add:

• Files and repositories — add whole repos, or better, specific files/folders that are actually relevant. Copilot searches the contents, but a smaller, targeted set of files gives better answers than dumping in an entire monorepo.
• Links to pull requests and issues — paste the URL, Copilot pulls in the content.
• Uploaded files — images, text files, rich documents, spreadsheets.
• Free text content — paste in transcripts, meeting notes, or anything else that doesn't live in GitHub itself.

Tip: when you add a repository as a source, Spaces always refers to the latest version of the main branch. There's no manual "refresh" step, it stays in sync.

Putting it to work

Once you've added sources and instructions, open the Space and start chatting. Your questions are grounded in everything you've added.

A practical example: create a Space per feature you're actively working on. Add the relevant source files, the design doc, and the tracking issue. Ask Copilot to summarize the implementation plan, suggest a reusable function, or check whether your approach lines up with a similar pattern elsewhere in the codebase. Follow-up questions in the same conversation keep using that same context automatically.

You can also switch which model answers your questions inside a Space, via the model dropdown at the top of the chat.

A word on cost

Questions you ask inside a Space count as regular Copilot Chat requests and consume AI credits based on the model and the number of tokens processed. If you're on Copilot Free, that counts toward your monthly chat limit. Nothing exotic, but worth knowing before you build a Space with a dozen large repositories attached.

More information

• Creating GitHub Copilot Spaces (GitHub Docs)
• Introduction to Copilot Spaces - Training | Microsoft Learn
• Speeding up development work with GitHub Copilot Spaces (GitHub Docs)

On the first of September, Tobi Lütke, the CEO of Shopify, posted something on X that interested me:

Training tiny models for special purpose use cases works so incredibly well if you have a great self improving recursive flywheel. Shopify ML team is on fire.

finetuned 0.8b model beats GPT 5.6-sol xhigh in this very specialized task. pic.twitter.com/w6OCWyWRi5

— tobi lutke (@tobi) September 1, 2026

The task he is referring to is called Buyer Profile. The finetuned 0.8 billion parameter model (a Qwen3.5-0.8B) scored 84.6 on their judge. The frontier model that trained it, GPT-5.6-sol at its highest setting, scored 83.0. The small model didn’t just keep up, it passed its own teacher. On top of that they compressed the system prompt from 9.1K tokens down to 1.1K, an 8x cut.

This pushed throughput from 2 million profiles a day to 72 million, a 36x jump! A model roughly 0.1 percent the size of a frontier model wins on quality, and runs dramatically cheaper and faster on this one task.

That last bit is the key here - “on this one task”. The headline reads like “small models beat big models now,” and that’s not quite true. What’s actually true is more useful and more demanding: for a narrow, high-volume task, a small finetuned model can beat a frontier model on quality, latency, and cost. But you only know you’ve won if your evals prove it on your data, and it’s only worth it if the inference savings outrun the cost of retraining as the task drifts. Let’s walk through why.

It isn’t a fluke

One vendor slide is one vendor slide. I’d not build a strategy on a single screenshot, and neither should you. The reason I take the Shopify result seriously is that it lines up with a pile of independent work that says the same thing.

Take LoRA Land from Predibase. In 2024 they finetuned 310 models across 31 tasks, using base models all under 8 billion parameters. After finetuning, 6 of the 10 base models beat GPT-4 on average, and all 10 beat GPT-3.5-Turbo. The tasks were the sort of thing you actually ship: named entity recognition, SQL generation, natural language inference, that sort of stuff. And they got there with as few as around 1,000 training samples per task.

Then there’s Google’s distilling step-by-step work from back in 2023, which is basically the ancestor of what Shopify are doing. A 770 million parameter model beat a few-shot-prompted 540 billion parameter PaLM. That’s a model over 700 times smaller coming out ahead. The trick was to train the small model on the reasoning the big model produced, not just the final labels. Teach it why, not just what.

The through-line across all three is the same. Take a big general model, use it to generate high quality training data for one specific task, and train a small model on that. The small model doesn’t need to know everything. It needs to do one thing, and it can do that one thing brilliantly.

Why this keeps happening to AI engineers

NVIDIA put out a paper last year with the very confident title “Small Language Models are the Future of Agentic AI”. Their argument is simple once you’ve built an agent. Agents don’t have sparkling open-ended conversations all day. They make the same narrow call, over and over: classify this, extract that, decide whether to call this tool, format this output. It’s repetitive, low-variation work.

And that’s exactly the shape where a small model is enough. You don’t need a frontier model’s general knowledge to decide whether a support ticket is about billing or shipping. You’re paying for a whole library when you only ever check out one book. NVIDIA reckon swapping frontier models for small ones on these calls can cut costs anywhere from 5 to 150 times, and they point at real deployments doing it.

If you’re building agents, most of what your agent does is probably a candidate for a smaller model.

The other move: don’t replace the model, route to it

There’s a step before “finetune a model for this task,” and it’s lower risk. You don’t have to bet a whole task on one finetune. You can just be smart about which model handles which call.

Think about how a multi-agent system actually works. You’ve got a supervisor deciding what happens next, and a bunch of sub-agents doing the actual work. There’s no rule that says every one of those has to be the same model. Anthropic’s Fable 5 farms tasks out to different models internally depending on the job. Models don’t need to be from the same family or provider. As I write this I’m engaged in a discussion on models with an AI group, and someone has just said they like Google’s Gemini as it’s a cheap way to execute plans created by Fable.

You can do the same thing on purpose in your agents: put a small, fast model at the front as your router or supervisor, let it do intent detection, and only hand the genuinely hard calls to the expensive frontier model.

Most requests are easy. If a small model can catch the easy majority and pass the rest up the chain, you’ve cut your bill without touching quality on the hard stuff.

This is well documented with real numbers. RouteLLM from LMSYS is an open-source router that cut costs by up to 85 percent while keeping about 95 percent of GPT-4’s quality on their benchmark. There’s a lovely bonus for the cost argument I’ll get to later: their routers generalise to new model pairs without retraining, so the routing layer itself stays cheap to run. NVIDIA’s own LLM Router Blueprint uses a roughly 1.7 billion parameter Qwen model purely as the intent classifier sitting in front of bigger models. That’s your supervisor, literally. And one documented case distilled a router down to a small model that cut routing latency from 5,000 milliseconds to 100 milliseconds while holding 92 to 96 percent precision.

The nice thing about routing is that it’s an on-ramp. You get a chunk of the small-model win without committing to a full task finetune, and if you get the routing wrong you can adjust it far more cheaply than you can retrain a model. If you’re going to try any of this, I’d start here.

Catch number one: you only know you won on your data

A small model that’s been finetuned or routed into a narrow lane fails in a nasty way when it goes outside of its capabilities. It fails confidently. When a frontier model hits something outside its comfort zone it often hedges or waffles, and you can see it. A small specialised model just gives you a crisp, wrong answer and moves on. Nothing in the output tells you it’s wrong.

There’s research that puts numbers on the risk. A 2025 paper describes what the authors call a “small model learnability gap”: below roughly 3 billion parameters, models struggle to absorb heavy chain-of-thought reasoning from a bigger teacher. Treat those thresholds as approximate, but the shape holds. It’s worth noticing why Shopify’s 0.8B model works despite being well under that line. Buyer Profile is an extraction and summarisation task, not multi-step reasoning. The task type decides whether the small model has a chance. There’s also a robustness cost: narrow finetuned models can drop by something like 36 percent when the input drifts away from what they were trained on. Scale buys you generality, and when you shrink the model you’re spending some of that generality.

So the only way to know a small model has actually won for you is to evaluate it on your own data, with your own judge, and to keep evaluating it as your traffic changes. This applies to routing too, and it bites harder there because a mis-route is silent. The router sends a hard query to the small model, the small model answers confidently and wrong, and unless you’re scoring the router’s decisions on real traffic, nothing ever flags it. Routing quality is itself a thing you have to measure.

This is the part people skip, and it’s the part that turns a nice demo into something you can run in production. You need evals in place before you trust any of this, and monitoring in place to catch the day your task quietly drifts.

Catch number two: the money maths

The other catch is the one that decides whether this is a good idea or a nice idea, and that’s cold, hard, cash.

The savings from a small model are per call. Every time you run inference, you pay less. Lovely. But the training is not free, and here’s the bit that trips people up: it’s not a one-off. Tasks drift. Your product changes, your users change, the distribution of inputs moves, and the model that was brilliant in July is mediocre by November. So you retrain. And every retrain re-spends the training cost, both in model training and engineering time.

That gives you a rough break-even to reason about:

savings per call × call volume, versus retrain cost × how often you retrain

When the left side wins, you’re golden. High volume and a stable task is the dream: Shopify running 72 million profiles a day on a task that doesn’t change much is exactly the case where the savings dwarf everything else. But flip it around. Low volume, or a task that drifts fast enough that you’re retraining every few weeks, and the maths can easily tip the other way. At that point the frontier API you were trying to replace might genuinely be cheaper once you count the engineering and retraining, and it comes with generality thrown in for free.

This is also why routing is the safe first move. The router generalises without constant retraining, so you dodge most of the retraining tax while still banking the per-call savings on the easy majority of requests.

Run the numbers before you build anything. If you can’t estimate your call volume and how often the task is likely to drift, you can’t tell which side of the line you’re on.

So where does that leave us

The temptation with all of this is to read “0.8B beats a frontier model” and conclude that small is just better now. It isn’t. Small isn’t the goal. The goal is the cheapest thing that provably clears your eval bar and keeps clearing it.

Sometimes that’s a finetuned 0.8B model doing 72 million calls a day. Sometimes it’s a small router in front of a big model, sending the easy 90 percent to the cheap path and the hard 10 percent to the expensive one. Sometimes, if your volume is low or your task won’t sit still, it’s just the frontier API and you should stop trying to be clever. The model size is a consequence of the decision, not the decision itself.

What you don’t get to do is guess. Every one of the wins above came with a judge score attached, and that’s not a coincidence. Build the evals first. Then you’ll actually know.

Tone - A brilliant, slightly obsessed professor talks about his favorite topic at the pub; relaxed and informative if you can get past the repitition and loose structure

What - instructions for building and using a zettlekasten or slip-box system for organizing research and writing.

Who - for students, academics, and nonfiction writers primarily but it may be useful for others

Read it When - you need to build a research bank on a topic in a quick and organized manner that will spark natural questions

% on Topic - Medium to High with a few digressions into history and the science of learning.

It feels like a lifetime since I posted my Books for Nonfiction Writers list, but it has only been a few weeks. In that article I said "This book will change how you think about writing papers." And that is certainly true, although to what extent will depend on your field and your willingness to experiment. But after a few weeks to settle and play with the system, I think it has changed the way I fundamentally connect information in my head, and that is very very cool.

While Ahrens is the author of this book, the idea of a Zettlekasten, or Slip Box, really started with the German scientist Niklas Luhmann in the 1960's, whose unique system of note taking helped him become one of the most prolific scientific thinkers and writers of the 20th century. Ahrens sets out to describe this system in some detail, and then gives arguments for adopting this method, with examples.

The original Zettlekasten was two plain wooden boxes of essentially index cards, one a "bibliography", with short notes on every article you read, and the other the "ideas box" containing a networked series of ideas, topics, and questions to presume. The original system involved a code to connect the ideas so they could be reconnected to each other in the future, but today's methods rely on simple hyperlinks.

Ahrens is very clear that the idea is not to form a collection of thought or an archive, but a network that encourages creative connections between nodes. Topics should be areas of your own interest, not just what is in the articles, they should be specific to you and require thought to make the connection. Ultimately the goal is to give you a system that sparks insights, creates research areas, and builds evidence for theories before they are even fully formed. Thinking, as he says many times throughout the book, is the main work. Everything is in support of generating and supporting networks of thought.

Ahrens also fills this text with lots of references to the science of learning (which makes sense as he is an Education researcher). He also gives examples of how to use the zettlekasten to build a research paper, though actual examples of working directly with the method are a little thin. That said, it seems to be a system you need to build for yourself so maybe those examples wouldn't be as useful as I think. Still, I felt the lack of concrete examples of actually using the method in the text.

Personally, I took his recomendation to use the technique with the notaking site Obsidian and ran with it. That has been working very well for me. There is a lot online about using Obsidian for writing, or as a zettlekasten if that's of interest to you. This book certainly has enough to get you started if that's what you are going for, but you could easily also do a bunch of reading online if all you want is some organizational ideas.

This book will either rock your world or leave you a little cold, depending on if you can see the relevance of the system to your own work. If you are doing any kind of reasearch it's worth a read just to see if the idea works for you.

If you'd like to buy this book based on this review, please consider using this affiliate link here to help support the site.

Buy on Bookshop.org

Roman Ugarte helped incubate and build Grok Bot, the popular new knowledge-work agent from SpaceXAI. A small, isolated team took it from first line of code to a working internal product in four weeks, and to a hugely successful public launch just three weeks later. Before Grok Bot, Roman led Growth at Cursor, where he helped scale the company from 15 people to over 1,000 before its acquisition by SpaceX.

In our in-depth conversation, we discuss:

1. The origin story of Grok Bot

2. The key decision to build it from scratch instead of adding it to Cursor

3. Why the team personally onboarded nearly 300 of its first users

4. The two early product decisions that made Grok Bot so successful

5. Their “colleague-pilled” product philosophy

6. Roman’s advice on moats, and what has allowed Cursor to keep winning in the most competitive market in the world

—

Brought to you by:

WorkOS—Make your app enterprise-ready, with SSO, SCIM, RBAC, and more

Mercury—Radically different banking, now with Command

—

Episode transcript: https://www.lennysnewsletter.com/p/how-we-built-grok-bot-in-a-month

—

Archive of all Lenny's Podcast transcripts: https://www.dropbox.com/scl/fo/yxi4s2w998p1gvtpu4193/AMdNPR8AOw0lMklwtnC0TrQ?rlkey=j06x0nipoti519e0xgm23zsn9&st=ahz0fj11&dl=0

—

Where to find Roman Ugarte:

• X: https://x.com/romanugarte_

• LinkedIn: https://www.linkedin.com/in/romanugarte

• Website: https://x.ai

—

Where to find Lenny:

• Newsletter: https://www.lennysnewsletter.com

• X: https://twitter.com/lennysan

• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/

—

In this episode, we cover:

(00:00) Introduction

(02:09) The origin story: building from scratch in one month

(08:40) Why Grok Bot was built as a separate product

(11:20) Manually onboarding a couple hundred people

(14:29) Hiding internal mechanics from users

(18:41) Timeline from beta to public launch

(19:14) Unshipping features and simplifying

(23:50) Early use cases and feedback

(26:50) Product philosophy: “Grok Bot can now”

(30:02) Cloud-first architecture

(33:12) The fresh-start advantage

(35:54) The vision: a true team of AI colleagues

(39:20) The “colleague-pilled” framework

(42:36) Work versus personal: one product or two?

(47:14) Long-lived agents, persistent memory, and the computer abstraction

(51:04) Grok Bot as an always-on infovore and chief of staff

(53:35) How fast the team moves and what preserves the startup feeling

(58:20) SpaceXAI pillars

(1:00:44) The first 90% vs. the last 10%

(1:03:30) Moving fast at scale

(1:06:40) How Cursor kept winning in the most competitive market in the world

(1:10:04) Company values: “deleting the product” and “just do the thing”

(1:11:45) Moats: discovered, not planned

(1:15:11) Tips for new users and power users

(1:18:00) Lightning round and final thoughts

—

References: https://www.lennysnewsletter.com/p/how-we-built-grok-bot-in-a-month

—

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.

—

Lenny may be an investor in the companies discussed.

Sheik Meeajaun: When Spillover Becomes Normal, Scrum Teams Stop Seeing the Cost

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

"A good Scrum Master makes their Product Owner look like a superstar." - Sheik Meeajaun

Sheik describes a team pattern many Scrum Masters recognize: spillover had become so normal that finishing the sprint felt like a special event. Refinement was weak, stories were often written during refinement instead of before it, and Product Backlog Items were sometimes little more than one-line titles. The Product Owner was not consistently engaged, standups had become update sessions for the PO, and nobody was connecting non-delivery to business impact. Sheik brought his Product Owner background into the Scrum Master role and started asking a more pragmatic question: what is the cost per sprint when we do not deliver? By making cost of delay visible, he helped the team see that spillover was not just a process issue. It was lost value. The experiments were practical: protect focus, prepare stories before refinement, and tackle the gaps at ground level instead of pretending the organization would fix everything first.

Self-reflection Question: What does your team treat as normal today that is quietly costing the product money every sprint?

Featured Book of the Week: The Scrum Guide by Ken Schwaber and Jeff Sutherland

Sheik does not pretend to have a long reading list. He says experience shaped him more than any single book, because contracting exposed him to many organizations and many versions of Scrum in practice. Still, he points listeners back to The Scrum Guide as the minimum reference every Scrum Master should know. For Sheik, the guide gives the vocabulary and foundation, but experience teaches the translation work: how those ideas survive contact with real teams, weak refinement, Product Owners who are stretched thin, and organizations that say "Agile" while still behaving like escalation machines.

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

Buy Now on Amazon

[The Scrum Master Toolbox Podcast Recommends]

About Sheik Meeajaun

Sheik is a seasoned product and Agile leader with over 20 years of experience scaling innovative, customer-centric digital solutions. A certified Scrum and Agile expert, he bridges strategy and execution, driving high-performance teams at enterprises like Rabobank and citizenM. As a hands-on builder, Sheik created Scrumling—a free, interactive Agile training platform—and ScrumJobs.net, a niche job board for Agile professionals. His passion lies in transforming theory into impactful, real-world results.

You can link with Sheik Meeajaun on LinkedIn.

You can also explore Scrumling, ScrumJobs.net, and Simatech.