Coder Legion - Recent posts tagged agile

How to bulk edit Azure DevOps work items without Excel (works on Mac)

Wed, 14 Oct 2026 13:45:05 +0000

title: "How to bulk edit Azure DevOps work items without Excel (works on Mac)"
published: true
description: "Open in Excel needs the Office add-in and Windows. Three ways to edit many Azure DevOps work items at once: bulk edit in the query, CSV import, or a spreadsheet grid in the browser."
tags: azuredevops, productivity, agile, tutorial
canonical_url: https://jr-devtools.com/guides/bulk-edit-azure-devops-work-items-without-excel/

cover_image: https://jr-devtools.com/bulk-editor/screenshot-grid.png

Disclosure: I'm the developer of Bulk Editor, one of the options mentioned below. Originally published on jr-devtools.com.

“Open in Excel” relies on the Azure DevOps Office Integration add-in: Windows only, and a frequent source of TF80012-style errors and Excel crashes. If you're on a Mac, can't install the add-in, or just want it to work, here are three ways to edit many work items at once.

1. Bulk edit in the query results (built in)

In a query or backlog, select several work items (Shift- or Ctrl-click), open the context menu and choose Edit. You can set one or more fields to the same value for all selected items, for example a new iteration, state or assignee.

Good: built in, nothing to install. Limit: every selected item gets the same value, so it doesn't help when each row needs its own estimate, title or tag.

2. CSV export and import (built in)

Run a query, export it with Export to CSV, edit the file in any spreadsheet app, and bring it back with Boards → Work items → Import work items. Rows with an ID update existing items, rows without one create new items.

Good: works on any OS, handles different values per row. Limits: rich-text fields such as Description are exported as raw HTML; errors only show up at import time; and nothing warns you if someone changed a work item after your export.

3. A spreadsheet grid in the browser

Bulk Editor (made by me) opens a query, a backlog selection or any list of work items in a spreadsheet-like grid inside Azure DevOps:

type in cells, use Enter and Tab, paste a block copied from Excel, and undo;
pick lists, required fields, states and area/iteration paths come from your own process, and invalid values are flagged before you publish;
nothing is saved until you select Publish, and a row that someone else changed in the meantime is refused instead of overwritten;
rich-text fields are never flattened; export to a clean .xlsx without HTML tags;
Pro: import .xlsx back, add new work items and children, and change parents in tree queries.

Good: nothing to install on your computer, works on Mac and Linux, different values per row with validation. Limits: Azure DevOps Services only for now; Pro is paid ($12 per organization per month), with a free plan of 25 published work items per organization per month and a 14-day Pro trial.

Which one should I use?

You want to …	Use
Move 40 items to the next sprint	Bulk edit in the query
Create a few hundred items once, from a plan someone sent you	CSV import
Groom a backlog: different estimates, titles and owners per row, regularly	A grid in the browser
Keep working in Excel on Windows with formulas	Open in Excel still does that, if the add-in works for you

Not affiliated with Microsoft. “Azure DevOps”, “Excel” and “Office” are trademarks of Microsoft.

The thinking behind Millrace

Thu, 30 Jul 2026 08:23:00 +0000

Did you ever notice how digital task boards are suddenly all the same horrid thing. Heavy engines of compromise that are as happy to supply a Gantt chart and resource plan as they are to give you a Kanban board.

Slow and steady, not slow and heavy

That moment of realization happened for me a few months back and I spent a great deal of time playing “Work Management Crossy Road” by jumping between all the available tools to find a new home for my work. I hated them all.

The thing that I found really disappointing was that the Kanban board felt so much like it was tagged onto something else. Something big, greasy, and hostile. Like when you realize that “Scrum Master” has decades under their belt as a pathological project manager. They will happily rename all their PMBOK shenanigans to remain employed, but their approach hasn’t changed a bit.

Finish the good stuff and let mediocre ideas fall away

My work method merges ideas from Getting Things Done at the big-rock level, and Personal Kanban to slice things up and stay focused on what really matters. That lets me apply Pomodoro Technique at the smallest scale to build up chunks of focus time that move things forward.

When it comes to a task board, that means creating a big-rock card with loosely formed ideas that I might choose to never work on. In fact, most of the ideas will be superseded by newer better ones and that’s a good thing. If the idea survives, I’ll slice chunks out of it and flow them across the board to get them done.

My up-next and in-flight columns need limits. These are the areas I need to carefully weed. Other columns tend to have their pace set by those two handling-time columns. Sometimes I like to break rules, so WIP limits are a visual thing, not an enforced policy.

Because all my work tends to happen on a screen, I like prominent links on the card, so I can teleport to where the work is without opening up the card. While I reject the idea of a due date, I do like to have my tasks wake up at relevant moments, so a next-action date is useful.

To reflect on my work, I like to review my completed items each week. If I can tag the crucial stuff, I can see if it’s making it all the way to “done”. A few tasteful charts can be useful in checking myself when I go off the rails. They help direct me to areas that need improvement, which is helpful.

A certain level of polish

There also needs to be a certain level of polish. The user interface doesn’t have to spark a new trend in app design, but what I can’t tolerate are paper cuts. A small irritation that I scrape past every time I check in on my work is a sure-fire productivity killer.

When I was trying out all these “productivity tools”, I kept finding blatant, reproducible, and distracting issues. Like one tool where I added a new card to the board only for it to vanish as I was typing in the title. The steps to reproduce this involved moving a card that triggered an automation, then adding a new card before the automation completed. This would be a forgivable edge case if this wasn’t one of the most common moments you might add a new card.

Or maybe it’s the tool that only let you add links to the rich-text field. Copy. Type. Locate icon. Click. Paste. Nope. On top of this, you could only see the link by opening the card. That’s too much friction when I have links on around 60-80% of my cards.

A tool you use occasionally can have a rough patch or two, but one you use to orient your day and manage your energy has no room for splinters.

Calm, slow, smooth, fast

The thing is, we’ve all seen someone trying to achieve something under pressure. They transform from a sentient human into a comedic slapstick actor. You know what I mean! They are baking a cake and it’s boring to wait for stuff to happen, so they start doing other things at the same time. Maybe they wash up some of the bowls and spoons. No big deal.

But then they catch a hint of that unmistakable burning smell. Oh no! The cake is burning. It’s not just that their calm has gone, the whole chain of calm-slow-smooth-fast has collapsed.

They whip their hands out of the washing up bowl, splashing water over the kitchen floor. They make an urgent grab for the oven glove, but knock it off the worktop. They pick it up, pull open the oven door, and use the half-on glove to grab the baking tray. The start to pull the cake out of the oven, burn the bit of their hand that isn’t in the glove, and just before the cake gets flopped upside down on the floor they realize that the burning smell was just a thin edge catching.

As the cake splatters on the floor, they realize it could have done with another ten minutes. Now it’s ruined. They should probably run their hand under a cold tap, but before they get to the sink they’ve slipped up on the wet floor.

It’s ridiculous. I agree. But this is how most people approach their work. They are over-burdened and their response is to make the work harder.

That’s why your Kanban board needs to be a source of calm. Calm is slow. Slow is smooth. Smooth is fast.

Fin

And that’s it. That’s the thinking. I didn’t build a Kanban board. I created a calm space to think about my work, my energy, and my impact.

Am I Deployable?

Wed, 01 Jul 2026 09:00:00 +0000

Tony Kelly hosts our latest episode of Continuous Delivery Office Hours, with Bob Walker and Steve Fenton.

In this episode of Continuous Delivery Office Hours, we ponder how you know whether your software is deployable so you can be confident you're meeting the Continuous Delivery (CD) principle of being deployable at all times.

To ensure software is deployable, teams must shift from manual testing to automated pipelines. Automation provides immediate feedback, captures institutional knowledge, and reduces long-term costs. Strategies like the Strangler Pattern help modernize legacy code for greater reliability.

Books mentioned in this episode:

Continuous Delivery by Dave Farley and Jez Humble
Extreme Programming Explained by Kent Beck
Seeing Like a State by James C Scott
The Phoenix Project / The Unicorn Project by Gene Kim et al
Toyota Production System by Taiichi Ohno

Why Agile Does NOT Mean "We'll Figure It Out Later”

Mon, 22 Jun 2026 07:58:47 +0000

One of the first things I learned about Agile was that it is flexible and always welcomes change.

In my experience, requirements changed almost every single time, customer feedback arrived midway, and sometimes even a new idea suddenly became much more important than the original plan. But Agile always helped me to adapt to all these changes. And this was probably the biggest reason why Agile became so popular in modern software development.

I always thought plans were supposed to give you some sort of direction. So when I read that Agile was all about welcoming change, my brain was like… Huh… wait, then why even bother planning?

This sounded completely reasonable at first, and that’s exactly where I ended up believing that Agile means "I'll figure it out later." But that’s not what Agile is trying to help teams achieve.

So if Agile isn't against planning, then why does this misunderstanding even exist? Or honestly, what does Agile planning actually look like, if not “figure it out as you go”?

That's what this blog is actually all about.

If Agile Welcomes Change, Why Plan At All?

Before I talk about Agile, I will tell you a simple scenario which always happens to me, and might have happened to you as well.

When I plan a trip with my friends, I tend to decide things beforehand, like where we will go, how much budget we will need, where we will stay, and which places we will visit.

Creating that plan does not guarantee that everything will happen exactly as I expected. Every other time, or sometimes it feels like every single time, ticket prices increase before I even start booking. Sometimes, the place that I planned to visit gets temporarily shut down due to some XYZ reason. Also, nature does not work by my direction, which somehow always manages to ruin my plan and eventually my mood, but anyways.

These things do not make the plan useless. Due to the unexpected changes that can happen later, I would not stop planning altogether. In fact, the reason I plan is because I do not want to get lost when those unexpected changes happen. A plan gives me a starting direction and helps me get going.

Basically, I'm trying to make a very simple point here — having a plan does not eliminate uncertainty. But uncertainty does not make planning pointless.

Even though planning and change can live together in everyday situations like a trip, many people still believe Agile and planning cannot coexist.

And this myth has a very specific origin.

Where The "Agile Means No Planning" Myth Comes From

For me, the answer started while I was going through a document called the Agile Manifesto.

The Agile Manifesto is a foundational document created by a group of software developers. It introduced four core values and twelve guiding principles that helped shape modern Agile practices.

One of its most well-known values is:
Responding to Change Over Following a Plan

The first time when I read that statement, I paused for a moment. Responding to Change Over Following a Plan. Hmm… Interesting. My immediate reaction was something like: "Wait a minute. Is Agile basically telling teams not to plan?"

And honestly, I can see why this statement confuses so many beginners. After all, if responding to change is considered more important than following a plan, then doesn't that make planning less valuable? At least that's what I thought.

Without even realizing it, my brain interpreted the statement into something completely different.
"Plans are useless."
"Things will change anyway."
"Let's just figure things out as we go."

Looking back, this is exactly where my misunderstanding started. But after spending more time understanding Agile, I realized that the statement was never trying to communicate any of those things. The problem wasn't Agile itself. The problem was and still is how the message often gets interpreted.

Once the statement is looked at through the lens of “planning doesn't matter”, it becomes very easy to assume that planning is unnecessary in Agile. It's easy to imagine a team simply starting the work and figuring everything out along the way. But software development rarely works as smoothly as assumptions do.

The moment multiple people, deadlines, and changing requirements enter the picture, assumptions fall apart. And this is not something random, I've actually experienced it. That's when the gap between assumptions and reality becomes much easier to notice.

What Happens When Teams Truly Stop Planning

Recently, me and my team were building a financial dashboard application for managing personal finances. We planned to develop features like user registration, dashboard components, transaction form, account creation form, and many more.

We started developing immediately without first deciding what to build first and what mattered the most. One of us jumped straight into the account creation form. I think someone else was into the transaction form. And I guess, someone was busy tweaking the UI. But anyways, the core personal financial dashboard functionality was still incomplete.

At first, this didn’t even look like a problem. We all were busy doing some sort of work. But when I looked closely, I understood that was exactly the issue. No matter how good our individual features were, but our users still couldn’t see any dashboard components for financial data analysis and management.

That’s when it hit us. If people can’t even do the one thing the app was supposed to let them do, then we're not building the right things. So we ended up spending lots and lots of our time building features that didn’t actually move the product forward. That’s when planning stopped feeling optional to us.

And I think that’s true for basically every software project, not just ours. Writing code matters. Building features matters. But knowing what to build first? That matters just as much.

Without that clarity, it’s easy to lose sight of what you’re trying to build — exactly what happened to us.

Agile Never Removed Planning — It Removed Excessive Planning

When I first started learning Agile, I assumed that being flexible meant constantly expanding the plan whenever a new idea appeared.

While building one of my projects called imaginAI, an AI image generation SaaS app, I spent a lot of time thinking about features before the product was even ready. The original idea was fairly simple. Users would enter a text prompt and generate images. I had already planned things like the landing page, image generation workflow, and payment integration.

But as development progressed, new ideas kept appearing — credit-based system and custom authentication mechanism. None of these were bad ideas. Some of them would eventually become useful additions to the product.

The problem was that I started focusing on those ideas before delivering the primary objective of the product itself. Instead of moving closer to a usable product, I was continuously expanding the scope of what needed to be built.

And that's when I learned an important lesson.

I realized that Agile was never against planning. I needed a plan, otherwise I wouldn’t know what I was building and why. What it actually pushed back against was the type of plan I was doing — one that kept growing instead of helping me start. I didn’t need a perfect plan for imaginAI. I needed enough of a plan to actually start, and the rest could be dealt with later.

Once I recognized that, I stopped treating every new idea as something that needed immediate attention. Some ideas could wait. The primary objective could not.

Since then, that small shift completely changed the way I approach every project.

The Different Kinds of Planning Happening Inside Agile Teams

By this point, I understood two things — removing planning creates problems, but Agile isn’t trying to eliminate it either.

When I was working on imaginAI, one mistake I initially made was thinking that planning happened only at the beginning of the project. I believed that once I had noted down the requirements and technical specifications, the planning phase was done. But as development progressed, I realized that planning was happening much more frequently than I originally thought.

I had a list of ideas and features I wanted to include in the product before starting the development. This included image generation, payment integration, a credit-based system, custom authentication, testimonials, example prompts, and several other ideas. In Agile, this kind of list has a name… the Product Backlog. It’s basically a master list of everything that might eventually become part of the product.

Having that list didn’t mean I had to build all of it right away. So before starting, I sat down and picked a handful of things to focus on for the first stretch. They were getting the core image generation flow working and a basic landing page up, nothing else. Turns out, that’s basically what Agile calls Sprint Planning. Instead of trying to build everything at once, I just picked a smaller set of work and focused on finishing that first.

While I was working on the first chunk of work, I started thinking about the future, like when I actually would put imaginAI in front of real users, and what absolutely needed to exist before releasing it. In Agile, that kind of bigger-picture thinking is often called Release Planning.

And even after a feature was ready, planning still didn't stop. After wrapping up the credit system, I still remember sitting back and thinking about what had worked smoothly and what hadn’t.

In a real team, this is the kind of thing that happens together, right after a sprint… everyone sitting down, talking through what worked and what didn’t, deciding what to do differently next time. I didn’t know it at that time, but that’s basically a Retrospective in Agile.

I noticed something kind of wild. And honestly, planning was happening before development started, during development, and even after the work was completed.

The simple difference which opened my eyes was that Agile does not treat planning as a one-time event. It treats planning as an ongoing activity that evolves alongside the product itself.

How Agile Plans Differ From Traditional Planning

Before I even started learning Agile, I was already familiar with several traditional software development approaches such as the Waterfall Model, V-Model, Spiral Model, and Iterative Development.

One thing I noticed across many traditional approaches was that a significant amount of planning happened right at the beginning. Teams would gather requirements, create detailed specifications, finalize designs, and only then move into development.

That’s actually why I started out planning everything upfront while building imaginAI. I had the database schema, the page flow, and most of the UI structure mapped out before writing a single line of code. I assumed that if I could define everything clearly at the beginning, development would become easier later on. At that time, nothing about that felt wrong to me.

Things got harder when I decided midway that I wanted users to revisit their own creations and be able to save them as well. This was something I hadn’t planned for in the original schema. Because I’d built everything around the earlier structure, this one idea meant going back and reworking decisions I thought were already final.

But once I understood Agile properly, I realized it approaches planning completely differently. Instead of planning the entire journey in detail before development even begins, Agile breaks things into smaller increments called Sprints. I could still define goals and make plans for imaginAI. But instead of locking everything in advance, I’d revisit and refine them as I go.

Here, I’m trying to keep a very simple and clear point. Both approaches involve planning. The difference is how each treats planning. One treats it as something that mostly happens before the work, while the other treats it as something that continues alongside the work.

And that's why Agile teams can remain flexible without feeling directionless.

So What Happens When The Plan Changes?

One thing I struggled to understand when I first started learning Agile was what teams were supposed to do when the original plan stopped making sense. For a long time, I assumed that if a plan needed to change, it meant that the planning was wrong in the first place.

That assumption got challenged pretty directly while working on SpendSense. When I was trying to show the app to a few potential users, most of them asked one simple question before even looking at the features or the UI — "Will I be able to see how much budget I have left for the month?"

And… I was like... Huh… Completely blank at that moment. This wasn't something I had planned for. It wasn't even sitting in my Parking Lot section. Account balances, transaction history, dashboard charts were the features I had built the app around. Suddenly they weren't what users actually cared about most.

The plan had changed. Now, I was left with pretty much only two options. I could either continue following the original plan simply because I had finalized it earlier, or I could listen to what users were actually telling me and update accordingly.

That was when my head started going in circles, not the song Circles… But anyways. I had planned carefully, I had made assumptions, I had finalized things. So if the plan now needed to change then surely I had planned wrong.

That's where I was misunderstanding something important about Agile. Changing a plan doesn't mean the planning failed. It means I know something today that I didn't know when I made the plan. My assumptions weren't wrong. They were just incomplete. And that's not a planning failure. That's just how building products actually works.

The goal never changed. What changed was the path to get there. And that's exactly why Agile treats plans as something to revisit, not something to protect.

If there's one thing Agile changed for me, it was the way I think about planning.

Earlier, I used to believe that a good plan was one that anticipated everything in advance. The more detailed the plan was, the more confident I felt before starting development.

But over time, I realized that software development does not work that way. Pretty much every time, something changes. Sometimes even the problem which I was trying to solve changed. This made me understand that no amount of upfront planning can completely eliminate that uncertainty.

Umm… not every project goes this way, honestly. Sometimes upfront planning works out just fine and nothing major changes. But in my experience, that's more the exception than the rule, especially when real users get involved.

What Agile actually taught me was that planning and flexibility are not opposites. In fact, I think having a plan is exactly what makes flexibility possible. Because without some direction, you're not being flexible, you're just being lost.

The goal is not to predict every possible situation before writing a single line of code. The goal is to know what you're building and why. And whenever better information becomes available, update the plan. That's not a failure. That's the point.

Looking back, the biggest lesson for me wasn't that Agile welcomes change. It was understanding that Agile welcomes change without losing direction.

And that's a very different thing from simply saying — "We'll figure it out later."

Millrace: Git-backed Kanban

Wed, 10 Jun 2026 13:12:33 +0000

Slow and steady, not slow and heavy

That moment of realization happened for me a few months back and I spent a great deal of time playing “Crossy Road” by jumping between all the available tools to find a new home for my work. I hated them all.

Finish the good stuff and let mediocre ideas fall away

A certain level of polish

A tool you use occasionally can have a rough patch or two, but one you use to orient your day and manage your energy has no room for splinters.

Calm, slow, smooth, fast

But then they catch a hint of that unmistakable burning smell. Oh no! The cake is burning. It’s not just that their calm has gone, the whole chain of calm-slow-smooth-fast has collapsed.

It’s ridiculous. I agree. But this is how most people approach their work. They are over-burdened and their response is to make the work harder.

That’s why your Kanban board needs to be a source of calm. Calm is slow. Slow is smooth. Smooth is fast.

Fin

And that’s it. That’s the thinking. I didn’t build a Kanban board. I created a calm space to think about my work, my energy, and my impact.

Shaped Kanban: Complete Features, Not Sprints

Thu, 04 Jun 2026 15:08:56 +0000

As an architect, a core part of my job is assessing viability and risk before committing a team to building something. That means understanding the problem deeply, testing critical assumptions early, and knowing when to change course. Sprint-based development fights me on every one of these. Planning ceremonies reward estimation speed over depth, sprint commitments pressure teams forward regardless of what they discover, and customer needs get filtered through velocity charts that measure team activity rather than delivered value.

The Timebox Problem

Interval-based development organizes work around fixed time periods, not around completing features. When timeboxes become the primary organizing principle, they corrupt even well-aligned teams.

The intention is sound: prevent endless work, create rhythm, establish accountability. Yet timeboxes attempt to enforce through calendar boundaries what discipline should provide naturally.

The Calendar Fills Itself

When discovery changes understanding mid-interval, teams are forced to ship incomplete work or carry it over. When planned work gets blocked, teams feel pressure to fill the remaining days with whatever fits: not the most valuable work, not what should naturally come next, just work that squeezes into the artificial deadline. In continuous flow, a free WIP slot takes the top-ranked item whatever its size, because no boundary is four days away. In a sprint, the days left tend to decide. A high-value item that won't fit gets passed over for a smaller one, or it gets started and carried over. The timebox itself becomes the constraint that dictates what work happens, not the actual priorities or readiness.

The timebox created the problem it was meant to solve.

Different Teams, Forced Cadence

Different team types operate on different natural cadences. Feature teams might deliver every few days while platform teams deliver every few months, yet many organizations force synchronization through universal sprint cadences because cross-team planning needs shared boundaries. The Scaled Agile Framework makes this explicit, aligning every team's iteration start and end dates within a release train.

Timeboxes also conflate three concerns that should be independent: development cycles, deployment cycles, and feedback cycles. Each operates at its own natural frequency, yet sprints tend to pull all three into alignment, stretching fast work to fill the interval and fragmenting slow work across multiple cycles.

The Scrum Guide doesn't require this coupling. It lets a team release an increment before the sprint ends, and it says the Sprint Review is never a release gate. But planning still happens at the boundary, and in practice feedback tends to batch at the review, where stakeholders inspect the work.

Ceremony Fuels Continuation Bias

Scrum's ceremony structure fails this most visibly. Sprint Planning commits you to work. Daily Standups report progress. Sprint Review demonstrates what was built. The Retrospective redirects for next time. No ceremony routinely asks the question that matters mid-sprint: should we stop this work two days in because the assumptions were wrong?

The Scrum Guide comes close. The Daily Scrum can adapt the sprint backlog, and the Product Owner can cancel a sprint whose goal has become obsolete. But adapting the backlog serves the sprint goal, and cancellation belongs to one role as an exception. Neither is a routine check on whether a piece of work should stop.

Without a ceremony that asks the question, many teams don't. They obfuscate and proceed because abandoning the sprint goal feels like failure, and the real failure gets deferred. A team that won't fail a design two days into a sprint is unlikely to throw away three sprints of committed work either. The sunk cost grows with every sprint, and each Sprint Planning recommits the team to it in front of stakeholders.

The redirect you needed was to fail early, not plan differently next time.

"We can't remove sprints; how would we know when things are done?" That question reveals the dysfunction. Scrum's own Definition of Done is meant to answer it without reference to the calendar. If a team still can't tell when work is done without one, it has a definition on paper but never developed genuine agreement on what "done" means.

When alignment exists, delivery cycles follow naturally. When alignment doesn't exist, timeboxes just create the illusion of progress.

Shaped Kanban: Discipline Without Shared Timeboxes

What if you could have discipline without a shared timebox organizing everyone's work?

Shaped Kanban combines rigorous upfront work definition with continuous flow. It takes the best ideas from Shape Up, shaping work before betting on it and using circuit breakers to bound risk, and applies them to Kanban's continuous flow model. Unlike Shape Up's fixed 6-week cycles, each piece of work has its own natural timeline within appropriate bounds.

Shaped Kanban replaces team-wide timebox mechanics with genuine discipline:

Shape work before committing - Define clear boundaries, identify risks, clarify what "done" looks like
Bet flexibly - Commit resources on a business cadence (quarterly, monthly) or on-demand as priorities shift
Use feature-specific circuit breakers - Each feature gets appropriate time bounds (3 days, 2 weeks, 6 weeks) based on complexity, not universal sprint durations
Flow continuously - Work moves through the system when ready, not when the calendar says so

This allows different team types (feature teams, platform teams, shared services) to operate at their natural cadences without artificial synchronization pressure. Coordination happens explicitly through dependencies, not through forced sprint alignment.

How Shaped Kanban Works

1. Shaping

Before work begins, senior people shape the problem and solution space. Not detailed specifications, but boundaries.

Appetite, Shape Up's term, defines how much time this problem deserves, not how long it will take. Instead of estimating bottom-up ("this will take 6 weeks"), you set a top-down constraint: "this is worth 2 weeks, not more." The appetite becomes a creative constraint that forces the question: what can we solve within this time bound? If you cannot shape a viable solution within the appetite, the problem either needs a bigger appetite or should not be worked on yet.

Shaping answers these questions:

What problem are we solving, and what is the appetite?
What are we explicitly not doing?
What does good enough look like within the appetite?
What assumptions are we making that, if wrong, would make this unviable?
Which other teams' work depends on this, and what does this depend on?

Shaping happens when needed, not on a fixed schedule. Work entering the system has clear boundaries, identified assumptions, and defined appetites instead of vague user stories.

2. Betting

Leadership commits resources to shaped work on a business cycle (quarterly, monthly) or on-demand as priorities shift.

The system maintains a hard separation between two artifacts. The Idea Archive is a PM-managed library of potential pitches sitting outside the development workflow. The Dev Backlog contains only accepted bets, each with a defined appetite and documented assumptions. Work moves from the archive to the backlog only when leadership places a formal bet, keeping the development queue clean.

Shaping and betting can happen as often as business needs emerge. Priorities can change before developers pull the work, capturing the benefit of short planning cadences while preserving context about which assumptions need testing.

Bets also give stakeholders the forecast a sprint used to give them. The appetite states what a feature is worth, and it doubles as a time budget. Each appetite is a ceiling. Add up the appetites queued ahead of a feature and divide by how many the WIP limit lets run at once, and the result is the latest that feature should start. That start date holds unless an earlier bet is extended or reshaped, or a new bet is placed ahead of it.

3. Circuit Breakers

Each feature has built-in boundaries, both temporal and assumption-based.

Temporal boundaries are feature-specific time limits: a simple CRUD screen might have a 3-day limit, a complex workflow with integrations might have a 6-week limit, and a research spike might have a 2-week limit.

A temporal boundary is still a time limit, but it differs from a sprint in what it controls. It belongs to one feature and is sized by that feature's appetite, and it exists to force a reassessment, not to decide what work happens. When it trips, there are no leftover sprint days to fill, because the next shaped item is pulled when capacity opens.

Assumption boundaries trigger when testing reveals the work is unviable. Critical assumptions defined during shaping get tested during implementation. If testing proves an assumption wrong and requires massive realignment, the circuit breaker trips and the work moves to Failed status for potential reshaping or Dropped status if unworkable.

When either boundary is hit, anyone building the feature can declare the trip, and work stops at once. The people who placed the bet then decide what happens next: adjust scope, extend, reshape based on what you learned, or drop the work. Stopping never waits for a decision. Only restarting does. An extension is a new bet with a new appetite that competes with the rest of the queue, and it shows on the board, so a quiet slip becomes a visible decision.

Per-feature boundaries also make failure localized. One feature can trip its circuit breaker while others continue flowing. In a uniform sprint, stopping mid-cycle puts the whole team's commitment in question, creating social pressure to keep going regardless of what you've learned.

With a per-feature breaker, the stop condition was written down before work began, so stopping carries out the plan rather than abandoning it. The appetite said what the problem was worth. It never promised the team would finish within it, so tripping the breaker is a smaller admission than abandoning a sprint goal. It still takes someone willing to declare it, which is why the failure section below treats tripping as a discipline.

4. Kanban Flow

Work flows continuously. When capacity opens, pull the next shaped and bet-on feature. The first order of business is testing critical assumptions identified during shaping, not building features, because the earliest moment to catch a wrong assumption is when a ticket is pulled. Then build until done or the circuit breaker trips.

Work items progress through clear states: Unshaped → Shaped → Accepted → Active → Completed, Failed, or Dropped. Progress tracking uses hill charts from Shape Up. Work is either uphill (still figuring it out) or downhill (executing on known work). This avoids the useless "80% done" claims that plague sprint burndowns.

A sprint boundary forces an inspection every few weeks. A six-week appetite has no such calendar checkpoint, by design. The assumption tests at the start and a hill chart stuck uphill do the job a sprint boundary was meant to do, and they raise the warning sooner.

WIP limits and circuit breakers work together. WIP limits constrain how many features run simultaneously, while circuit breakers bound how long any individual feature can run.

"Done" means the feature delivers the agreed value, period. Not "the sprint ended so we call it done."

5. Technical Debt Without a Cooldown

Shape Up's two-week cool-down between cycles handles work like technical debt and exploratory spikes that don't fit a formal pitch. Shaped Kanban removes fixed cycles entirely, which creates a real gap if left unaddressed.

Small items too minor to pitch, like a dependency bump or a half-day refactor, travel with the active feature that touches that code, inside its appetite, so shaping leaves room for them in scope. For anything larger, the answer is to reframe technical work so it can compete at the betting table. Every meaningful technical work item falls into one of three categories:

Corrections: mistakes actively hurting the business now, including security vulnerabilities, bugs driving churn, and reliability failures violating SLAs. These are risk mitigation bets, not engineering housekeeping.
Optimizations: improvements that translate directly into margin or efficiency, like reducing cloud spend, speeding page loads, or automating deployments. With numbers attached, they compete well.
Re-Alignments: work that unlocks future capabilities the roadmap depends on. Making the dependency explicit changes the conversation, since leadership is already implicitly betting on this work when they approve downstream features.

Technical debt framed as engineering work gets deprioritized. Framed as business risk, margin opportunity, or roadmap prerequisite, it can win bets. This demands more rigor than Shape Up's cool-down, but architectural health becomes visible and competes on the same terms as every other bet.

Multi-Team Coordination Through Explicit Dependencies

Multi-team coordination is hard. Shaped Kanban doesn't pretend otherwise. Scale deserves an honest answer.

Shape Up emerged from Basecamp's own product development, refined over years as the company grew from four people to over fifty. My own experience with Shaped Kanban at scale sits in that same range: three medium-sized teams working on the same broad system. I have also worked in organizations running Scaled Scrum. That is enough to project how the two approaches compare as teams multiply, though I won't claim confidence about enterprise-level deployments I haven't run.

The most significant dynamic at scale is continuation bias. I expect Scrum's greatest weakness to get worse as teams multiply. Scrum as commonly run operates on collective abstractions like sprint commitments, velocity charts, and planning poker (the last two aren't in the Scrum Guide, but they usually come with it). None of these give the people building a feature a pre-agreed trigger to stop it, and you cannot fix the collective without first empowering the individual.

Shaped Kanban's core mechanisms work at the level of the individual feature. Its appetite and documented assumptions give the people building it an explicit, pre-agreed trigger to stop, without waiting for a team-wide ceremony or a collective decision. Leadership decides what happens after the stop, not whether it happens. That is the lever I would reach for to prevent bad assumptions from propagating across a multi-team program.

Cross-team coordination in Scaled Scrum typically flows through the Scrum of Scrums meeting. But Scrum of Scrums is just another timeboxed event. It begins, it ends, and everyone returns to their sprint. It doesn't build an ongoing, async coordination discipline that is informed and purpose-driven. Scrum teams can write dependencies down too, but nothing in the sprint process requires it.

In Shaped Kanban, dependencies are explicit from the shaping stage. When one team's circuit breaker trips, the shaped work already lists the downstream bets that depend on it, and those teams hear at once rather than at the next sync meeting. Each team understands how their work connects to the broader program and why, which makes async coordination practical because the context is already documented rather than locked inside a recurring meeting.

Scrum's rigidity also tends to produce a common breakdown at scale: a small number of individuals, usually dev leads or architects, silently absorb all the cross-team coordination the process doesn't account for. They become the informal connective tissue holding the program together while everyone else follows the sprint. Shaped Kanban moves that load into shaping. Senior people still carry it, but the dependencies they find are written into the shaped work and visible to every team. They stop living in a few people's heads and inside ceremonies that can't actually handle them.

The genuine challenge is visibility. Shaped Kanban at scale requires roadmaps that are explicit about dependencies between epics and features. You cannot hide behind sprint abstractions and hope the pieces fit together.

How This Approach Can Fail

Shaped Kanban can be abused just like Kanban can be abused. The flexibility that makes it powerful also creates opportunities for dysfunction if discipline erodes.

How This Approach Can Fail

WIP limits must actually limit work. If WIP limits become suggestions rather than constraints and teams allow constant disruptions and context switching, the framework collapses into chaos. Kanban without strict WIP limits is just a glorified to-do list.

Priorities must be honored. Bet on work you know has high value, deliver the original priorities, and let the circuit breakers do their job. If every urgent request bypasses the queue or priorities shift weekly, you are practicing reactive chaos with a Kanban board.

Circuit breakers must trip. When work hits its time boundary or invalidates critical assumptions, stop and reassess. Do not extend deadlines reflexively. If you never let circuit breakers trip, they are theater.

Flexibility requires discipline. Without discipline, you have just removed the one forcing function that timeboxes provided while keeping all the dysfunction: poorly defined work, shifting priorities, and endless scope creep.

Timeboxes enforce rhythm mechanically while Shaped Kanban requires you to enforce rhythm through actual alignment and genuine agreement. When that agreement slips, it fails more visibly, because continuing past an appetite takes a new bet rather than a quiet carryover. Enforcing rhythm through agreement is harder than letting a calendar do it, so the willingness to change comes first.

When to Consider This Approach

If your organization struggles with timeboxes fragmenting work, teams forced into artificial synchronization, or discovery invalidating sprint commitments, Shaped Kanban might help.

It is the wrong move for a team without senior people who can shape work, or under leadership that won't honor its bets. A shared sprint cadence supplies a forcing function those teams can't yet supply for themselves.

Shaped Kanban requires these disciplines:

Define work with clear boundaries before committing
Start work with uncertainty, knowing you can stop and realign when assumptions break
Commit to specific outcomes with understood scope
Build until done or until constraints force reassessment
Measure whether you delivered value, not just whether you shipped

It is not a perfect solution. Continuous flow across teams demands more intentional coordination than synchronized sprints. But I will take that tradeoff every time. Explicit coordination makes dependencies intentional, while synchronized sprints leave them to hope until the next boundary.

Rhythm and tempo come from alignment and natural feature boundaries, not predetermined calendars. You cannot iterate toward value without agreement on what constitutes value. Shaped Kanban makes that agreement explicit, visible, and continuous, without requiring everyone to march to the same drumbeat.

How Sprint Planning Actually Works

Tue, 02 Jun 2026 20:19:31 +0000

The high-level view of software development looks pretty straightforward. A team gets requirements, starts designing, writes code, tests features, and finally delivers the product.

Simple… right?

But when you look deeper into how software development actually happens inside teams, the reality starts feeling very different.

What seems smooth from the outside rarely feels that smooth while building the product in real life.

Tasks change. Priorities shift. Bugs suddenly appear in between. New ideas get added while development is already going on. And before anyone even realizes it, the team is managing multiple things at the same time.

When work starts moving in too many directions together, things can get messy very quickly.

That is exactly where Sprint Planning comes into the picture.

Before teams start building anything, they need a moment to pause and get clear on the work ahead. Not in a heavy or overly formal way — but enough to make sure everyone is moving with the same understanding before the sprint begins.

Because when that clarity is missing, development may still start… but confusion usually starts with it too.

And that is what makes Sprint Planning such an important part of Agile teams.

In this article, we’ll understand how Sprint Planning actually works — in a much simpler and practical way, with relatable examples, without making it feel overly technical or textbook-like.

Why Modern Software Development Needs Better Planning

Have you ever wondered why teams struggle while building products even when everyone on the team is talented and knows what they’re doing?

At first, it feels surprising. Because when you look at it from outside, everything seems fine. Everyone is skilled, work is moving, code is being written, and development has already started.

So naturally, the question becomes — then where does the problem actually begin?

You might think maybe the team lacked coordination. Maybe communication broke somewhere in between. Or maybe there was confusion while people were working together. And yes, sometimes that can absolutely happen.

But many times, the real issue starts much earlier than that — even before development begins.

A lot of teams unknowingly begin with a very simple thought:
“Let’s just start building first. We’ll figure things out along the way.”

And honestly, this doesn’t feel wrong in the beginning. In fact, it feels faster.

Planning feels like extra work. Documentation feels time-consuming. Meetings feel unnecessary when everyone is already excited to start building something.

So the thinking becomes simple — why spend time planning now when we can use that time to code?

But this is usually where things slowly start becoming difficult later.

Because development may start fast, but keeping that momentum becomes difficult when the work keeps changing while the product is being built.

New requests come in. Priorities shift. Feedback keeps arriving. Small decisions made early start affecting things later. And gradually, work starts feeling heavier than it looked in the beginning.

That’s when teams realize building the product was never the difficult part. Managing the moving pieces around the product is where things become challenging.

That’s why modern software teams don’t see planning as “extra work” anymore.

They see it as something that creates enough clarity before development moves too far ahead.

But at the same time, planning everything months in advance doesn’t work either.

Because software keeps changing while it’s being built. User needs evolve. Product direction changes. And sometimes what looked important in the beginning doesn’t stay important later.

Which means teams needed a better way to plan work — without trying to predict everything too far ahead.

That shift changed how modern teams started building software.

And that is where smaller development cycles entered the picture.

How Smaller Development Cycles Changed Modern Teams

Earlier, many teams used to build large parts of a product over a long period before releasing anything to users. Sometimes it would take months before users could even see what was being built.

At first, this approach sounds practical. The thinking feels simple — finish everything properly first, and then release it once it’s fully ready.

But in real software development, things rarely stay the same for that long.

While the team is busy building, user expectations keep changing. Feedback keeps evolving, market needs shift, and sometimes even the product starts moving in a slightly different direction midway through development itself.

And by the time everything is finally ready, some parts may already feel outdated or need changes.

That’s where teams started facing a bigger problem.

They were spending a lot of time building, but learning very late whether they were actually building the right thing. And making changes late in development is never easy — it usually takes more time, more effort, and sometimes means reworking things that already felt completed.

That’s why modern teams slowly started moving away from one long development cycle.

Instead of building everything together at once, they started breaking work into smaller parts and delivering it step by step. This made it easier to release earlier, learn earlier, improve earlier, and keep moving with real feedback instead of relying only on early assumptions.

Think about an app like Rapido or Uber.

Imagine trying to launch it with everything built together at once — login, booking, payments, live tracking, notifications, offers, ratings, support, and every other feature in one go. It would take a huge amount of time before users could even start using it.

Instead, teams usually start with something smaller. They release the core experience first, let users start using it, and then keep improving the product gradually over time by adding more features in future updates.

This way, users start getting value much earlier, while the product keeps improving step by step instead of waiting until everything is fully completed.

Breaking work into smaller cycles helped teams adapt faster and learn earlier. But it also created a new challenge — making sure every new cycle begins with enough clarity before the actual work starts.

So What is Sprint Planning Actually?

Once teams started working in smaller development cycles, something else naturally became important.

Every cycle needed a proper beginning. Because teams can’t simply jump into work every few weeks and expect everything to automatically fall into place.

Before development starts, there usually needs to be a quick pause.

A moment where everyone comes together, looks at what’s ahead, talks things through, and makes sure the sprint begins with shared understanding instead of assumptions.

That is what Sprint Planning feels like in real teams.

It’s less about meetings for the sake of meetings, and more about giving the team a clear starting point before the actual work begins.

Because once development starts moving, things move fast.

People get busy in their own tasks. Different parts of the product start moving together. Conversations happen alongside coding. And there’s often very little time to stop and rethink once the sprint is already underway.

That’s why teams usually take this time beforehand.

Not to over-plan everything. Not to predict every situation in advance.

Just to align around the upcoming work, build a shared understanding, and begin with better clarity together.

And that small pause before the sprint begins often saves a lot more time later while building.

Where Does All The Work Come From?

While understanding Sprint Planning properly, one question naturally comes up first:

Where does all the work actually come from?

Because before a sprint begins, the team already has work in front of them. Features need to be built, bugs need fixing, improvements keep coming up, and new ideas keep getting added over time.

So naturally, all of that has to come from somewhere. And if you think about it closely, the answer is actually pretty simple — it starts with the users.

Because at the end of the day, every product is being built for someone to use. And once people start using it, their experience with the product starts shaping what happens next.

Think about apps like Swiggy or Zomato.

Suppose users start wanting the option to order from multiple restaurants in one single order. If enough people keep asking for something like that, the company starts paying attention. Because now it’s no longer just an idea — it becomes something users genuinely care about.

And this is how many product improvements usually begin.

Users may never directly sit with developers and explain what to build. But through reviews, feedback, complaints, feature requests, and even the way they use the product, they constantly shape how the product evolves over time.

Now obviously, thousands or millions of users can’t directly join the team’s discussions. So someone needs to represent that perspective inside the team. And in Agile teams, that role is usually handled by the Product Owner.

You can think of the Product Owner as someone who stays close to both sides — understanding what users are experiencing, while also staying connected with the product and the team building it.

Over time, all those needs, requests, improvements, fixes, and ideas start gathering in one place. And that running list is what teams call the Product Backlog.

It’s simply a place where upcoming work lives before the team begins working on it.

And that’s usually where the team looks before a new sprint begins.

How Teams Decide What Fits Into a Sprint

As soon as the team has the Product Backlog in front of them, one important question naturally comes up:

What can actually be taken into this sprint?

Because the backlog usually contains much more work than the team can finish in one cycle. There may be multiple features, fixes, improvements, and ideas waiting there together — but obviously everything cannot be picked at once.

So the team sits together and starts looking through the upcoming work. They discuss what feels important right now, what makes sense to take next, and what can stay for later.

But this is not just about picking work from a list.

The bigger conversation usually begins when the team starts understanding how much work something actually involves.

Because sometimes a task looks very small from the outside… until people start talking through what it really includes.

Take a login feature for example.

At first it sounds simple — just add login to the app.

But once the team starts discussing it properly, more things begin appearing around it. Authentication, validations, password reset, session handling, security checks, database connection, error states — and suddenly the same task feels much bigger than it looked in the beginning.

And this is exactly why teams discuss before deciding.

They try to understand the work from different angles before bringing it into the sprint. Sometimes it feels smaller than expected. Sometimes much bigger. And many times the real effort only becomes clearer after the conversation begins.

Teams also look at how much work feels manageable for the upcoming sprint based on the time and people available during that cycle.

And once that clarity starts forming, some work gets picked for the sprint, while the remaining work stays in the backlog until a later time.

And that’s completely normal.

Sprint Planning is rarely about fitting everything in.

It’s more about starting with a realistic amount of work that feels clear enough for the team to move forward together.

Why Sprint Planning Often Fails in Beginner Teams

Even after understanding how Sprint Planning works, many teams still struggle with it in real life.

And honestly, that's a challenge most teams face when they start applying it.

Almost every beginner team goes through this phase at some point. Not because they lack skill, and not because they’re doing something terribly wrong — but because planning feels much easier from the outside than it actually feels when the team sits together to do it.

One of the most common things that happens is teams take on more work than they realistically should.

At that moment, everything feels doable. A task sounds manageable, then another gets added, then one more joins because it feels important too. And slowly, without anyone noticing, the team commits to more than it can comfortably complete.

This usually doesn’t happen because the team is careless. In fact, it often happens for the opposite reason.

People feel motivated. Everyone wants progress. Everyone wants to move fast. And when useful work is sitting in front of you, saying “let’s take this too” feels much easier than pushing it to later.

Another place where teams struggle is during discussion itself.

Sometimes everyone walks out of Sprint Planning feeling aligned — but once work begins, people realize they were understanding the same task in slightly different ways. And that small difference becomes visible only after development starts.

Someone imagined a basic version of the feature. Someone else thought edge cases were included. Another person assumed part of the work was already covered somewhere else. And suddenly a task that looked clear in the meeting starts creating confusion during the sprint.

That’s why Sprint Planning usually works best when teams keep the conversation practical and honest.

Not rushed just to move faster. Not overloaded just to fit more work in. And not based on assumptions like “we’ll somehow manage later”.

The goal is simply to make sure everyone starts with enough clarity before the sprint begins. Because when that clarity is missing in the beginning, teams usually spend far more time fixing confusion later.

And that’s exactly where many beginner teams struggle without even realizing it.

Sprint Goals — The Part Most Teams Ignore

Once the team has decided what work will go into the sprint, it can feel like Sprint Planning is pretty much done. Tasks are selected, discussions are finished, and everyone feels ready to start building.

On the surface, everything looks sorted and clear. But even after all that, there’s still one small thing many teams forget to talk about before the sprint begins.

And surprisingly, that one small thing can completely change how the sprint feels later.

The question is simple:

What are we actually trying to achieve in this sprint?

Because a sprint usually isn’t just about picking tasks and completing them one by one.

If the sprint is only a list of unrelated work items, the team may stay busy the entire time — but the work can still feel disconnected while doing it.

This is exactly where Sprint Goals start becoming useful.

A Sprint Goal gives everyone one common direction behind the work already selected.

It brings all those individual tasks under one bigger purpose, so the sprint feels connected instead of scattered.

For example, imagine a sprint includes fixing login issues, improving password reset, and adding email verification.

These look like separate tasks when written individually. But when you step back and look at them together, they’re all improving one part of the product — the login experience for users.

And suddenly the sprint feels much more connected.

Different people may still be working on different pieces, but everyone is contributing toward the same outcome.

Now compare that with a sprint where one task is a small UI fix, another is a payment issue, another is dashboard cleanup, and something else is unrelated backend work.

All useful tasks. But together, they may feel like separate pieces moving without one clear direction.

That’s why Sprint Goals often help more than teams initially expect.

They create focus without making the process heavier. They help everyone stay aligned while working, and they make the sprint feel less like “just finishing tasks” and more like building toward something together.

It’s a small part of Sprint Planning. But many teams only realize how important it is once they start working without one.

Sprint Planning is Not About Predicting Everything Perfectly

After reading everything so far, it’s easy to get the impression that Sprint Planning is supposed to make the entire sprint go exactly according to plan.

The team discusses the work beforehand, agrees on what it plans to build, and starts the sprint with much more clarity than before.

And honestly, that sounds great.

But real software development has a habit of reminding us that reality often looks different from the original plan once the actual work begins.

Think about your own plans for a moment.

Have you ever planned your entire day perfectly in the morning, only for something unexpected to appear a few hours later?

Maybe a new task showed up. Maybe something took longer than expected. Maybe your priorities changed halfway through the day.

Software development is not very different.

Even when a sprint starts with a good plan, the team keeps learning while building. New information appears. Better ideas emerge. Sometimes the team discovers things they simply couldn't have known during Sprint Planning.

And that doesn't automatically mean something went wrong. It just means the work is now being seen more clearly than before.

This is exactly why Agile teams don't treat Sprint Planning like a prediction exercise.

The goal isn't to figure out every single thing that will happen over the next few weeks. The goal is simply to begin with enough clarity so the team can move forward together. And if something changes later, the team adapts and keeps moving.

Because Sprint Planning was never about creating a perfect future.

It was always about creating a better starting point.

Before understanding how Agile teams work, Sprint Planning can easily look like just another meeting on the calendar.

A meeting that happens before development starts. A meeting people attend because the process says they should.

But once you look at everything happening behind the scenes, it starts feeling very different.

A team isn't just writing code. People are discussing ideas, building features, fixing problems, making decisions, and working together on the same product at the same time.

And when all of that starts moving without enough clarity, even simple work can become harder than it needs to be.

That is why Sprint Planning exists.

Not because Agile requires another meeting. Not because teams enjoy spending time planning. But because spending a little time thinking together before building is often much easier than dealing with confusion later.

And maybe that's the biggest takeaway from Sprint Planning.

The goal was never the meeting itself. The goal was helping teams spend more time building and less time figuring things out along the way.

Because once the sprint actually begins, the conversations don't stop. The decisions don't stop. And the collaboration doesn't stop either.

In many ways, Sprint Planning is simply the point where the sprint starts — not where the work ends.

Agile Explained Simply for Beginners

Fri, 22 May 2026 20:24:38 +0000

Software development sounds pretty straightforward at first, right? Build the product, test it, and deliver it. Done.

But here's the thing — in reality, things rarely go exactly as planned.

Requirements change midway through development, new ideas pop up unexpectedly, deadlines shift, customer expectations evolve, and sometimes even a technically correct product may still not feel right to users.

This is exactly one of the biggest reasons why Agile became such a widely used approach in modern software development.

But despite being used almost everywhere today, Agile still sounds confusing to many beginners, and honestly, even to some experienced software developers.

So instead of learning Agile through complicated book-ish definitions, let's try to understand it in a much simpler and more practical way with examples.

What is Agile?

Let’s start with the word itself.

If a person can move quickly and adapt easily to situations, then what do we call such a person? Agile, right? Someone with great agility. In the similar fashion, Agile in the tech world is not rocket science. It is simply an approach that helps teams adapt to changes, improve continuously, and solve problems step by step instead of all at once. That's it!

Why Agile Exists

Let's understand the existence and need for Agile with an example. Imagine a team is responsible for delivering a ready product to a client and its users.

What would a normal team do if Agile did not exist, or if they were unaware of it? They would simply start developing the product from start to finish in one go.

Now, suppose in the middle of development, the client suddenly requests a change in the product — it could be anything. What would the team do now? They would first try to adjust the existing development, but making changes at that stage becomes difficult, messy, and expensive. In most cases, team may even need to rework large parts of the product from scratch again.

This is the problem Agile helps solve. Agile follows a proper process throughout the project timeline. Traditional methodologies often faced adaptability issues. They were time-consuming, costly, and resource-heavy. Agile, on the other hand, focuses on adapting to changes quickly, which helps reduce extra cost, optimize resources, and save time, which ultimately helps teams deliver products faster.

As a result, teams can respond to changes more comfortably without rebuilding everything from scratch.

And that is exactly why Agile became a game changer for modern teams.

Agile Mindset

Agile as an approach does not just help with product development. It also improves the way a person thinks while solving problems. Instead of getting overwhelmed by the final goal, Agile teaches us to focus on smaller manageable tasks step by step.

And that is where the concept of Agile Mindset comes in. To properly follow Agile, both the development process and the mindset should work together.

But now the question is — how does the mindset even matter in development?

Let's understand this with a simple example.

Suppose a team is building a ride-sharing app. It can have multiple features like bike booking, metro ticket integration, live tracking, ETA prediction, reward coins, and many more. Now imagine that one newly assigned feature feels very complicated to a developer, and they start stressing about how everything will work together.

This is where Agile Mindset helps. Instead of stressing about the entire product all at once, the team focuses only on the current small goal they need to complete right now.

For example, first complete login functionality, then implement booking, then add tracking, then improve payments, and likewise complete the product. It is like taking one step at a time.

This reduces mental clutter and helps teams work more clearly and efficiently.

And interestingly, Agile is not useful only in the tech world. Its way of thinking can also help in business, teamwork, self-improvement, and even real-life situations.

Think about success in real life. Nobody becomes successful overnight, right? A business usually starts small and grows gradually with time, learning, mistakes, feedback, and continuous improvement. People first achieve smaller goals before finally reaching something big.

That's the real power of Agile Mindset — solving big problems by focusing on one meaningful step at a time.

Why is Agile Called an Iterative Approach?

So far, we can understand that Agile follows an Iterative Development approach, unlike traditional development models such as the Waterfall Model or V-Model, which usually follow a Linear Development approach.

But before understanding Iterative Development more clearly, we first need a very basic understanding of Software Development Life Cycle (SDLC).

Every software product usually goes through a development process before reaching users. In simple terms, SDLC is the overall process followed to build software.

The process usually starts with requirements gathering and planning, where the team understands what needs to be built. Based on those requirements, design specifications are created for the product. Once the planning and design are ready, the development process begins, where the actual product is built. After development, the product goes through testing to identify bugs and verify whether everything is working properly. Finally, the product is deployed for customers to use.

Refer to the image below for a visual representation of SDLC.

Now, here’s where the real difference begins.

In traditional models like Waterfall Model, these stages are usually completed one after another in a fixed sequence. This means the customer often has to wait until the very end before receiving the complete product.

But Agile approaches development differently.

Instead of building the entire product in one long cycle, Agile breaks the product into smaller parts and repeats these development phases multiple times in short cycles called iterations. In the tech world, it is referred to as sprints.

For example, a small feature is planned, then designed, then developed, then tested, and finally the product is delivered. Of course, it may contain limited features at first, but it is still usable for users. Then the same cycle repeats again for the next feature. This allows teams to continuously improve the product, gather feedback early, and adapt to changes more easily during development instead of waiting until the very end.

And because these process keeps repeating again and again throughout the project, Agile is called Iterative Development approach.

Refer to the image below to visually understand the difference between Agile and Waterfall development approaches.

Why Customer Feedback Matters in Agile

One of the biggest advantages of Agile is continuous customer feedback throughout the development process, unlike traditional models like the Waterfall Model, where customers usually see the final product only after the entire development process is completed.

This creates a major problem.

What if the customer changes the requirements midway? What if the delivered product does not meet their expectations? Or what if users simply do not like how a feature works?

At this stage, making changes can cost a lot in terms of time, money, as well as resources and infrastructure because a large part of a product is already built.

Agile tries to solve this problem by involving customers and stakeholders throughout the development process instead of only at the end.

As we discussed earlier about Agile development which happens in small iterations or sprints, teams get a chance to regularly show progress, collect feedback, and adapt accordingly.

For example, instead of developing an application continuously for six months or even a year and then shipping it only after completion, an Agile team may first deliver a small working version with limited features. Based on customer feedback, improvements and changes are then made to the product in the upcoming sprint or iteration.

This creates a continuous feedback loop where the product keeps improving at each iteration throughout the development process.

Because of early and regular feedback, problems can be identified much sooner. Teams can quickly adapt to the changes before problems become too costly or difficult to manage.

This not only helps teams deliver a better product, but also increases the chances of building something that actually matches customer expectations and real user needs.

Refer to the image below to understand how continuous feedback leads to continuous improvement in Agile development.

Flexibility and Adaptability in Agile

As mentioned earlier, requirements rarely remain the same from start to finish. This is one of the biggest challenges in software development.

New business ideas appear, customer expectations evolve, market trends change, and sometimes problems are discovered during the development phase itself.

This is where traditional development models often struggle. Making changes late in development can affect a large part of the project, right?

Agile is designed to handle such situations more comfortably.

Using the same ride-sharing example we discussed earlier, imagine that a client suddenly requests a new feature midway through development. In that case, Agile teams can prioritize and include it in upcoming sprints without heavily disrupting the overall workflow.

This makes Agile far more flexible and adaptable for real-world project environments, where changes are not just common, but often unavoidable.

Important Agile Concepts Everyone Should Know

While learning Agile, you'll definitely come across certain terms again and again. At first glance, they may sound too technical, but once you understand them in simpler terms, they become much easier to understand and implement during the actual development process.

1. User Stories

User Stories are simple descriptions of a feature from a user's perspective.

Instead of writing hundreds of lines in requirement documents, Agile teams usually prefer explaining features in a much simpler way by focusing on what the user wants and why they need it.

2. Story Points

Not every task requires the same amount of effort, right? Some tasks may be simple, while others may be more complex.

Story Points are used to roughly estimate how big, complex or difficult the task is compared to others.

3. Product Backlog

The Product Backlog is basically the master to-do list of the product.

It contains tasks related to features, improvements, bug fixes, ideas, and other things that may be worked on during development.

4. Sprint Backlog

The Sprint Backlog is nothing but the set of tasks or user stories the team plans to complete during the current sprint.

You can think of it as the team's short-term work plan.

5. Sprint

A Sprint is a short development cycle where the team works on a specific set of tasks or features, basically the Sprint Backlog, within a fixed duration.

At the end of a sprint, the goal is usually to deliver some kind of working improvement in the product.

6. Scrum or Daily Standups

Scrum, often referred to through Daily Standups, consists of short team meetings held regularly during development.

Team members quickly discuss what they are working on, what they completed, and whether they are facing any issues or blockers.

You can think of it as a quick daily progress update within the team.

7. Retrospectives

At the end of a sprint, teams often conduct a Retrospective.

This is basically a discussion about what went well, what did not go well, and what can be improved in the upcoming sprint.

8. Velocity

By hearing the word Velocity, you probably started thinking about the physics term “velocity”, right? And honestly, that's completely understandable.

But here, Velocity simply refers to how much work a team is usually able to complete during a sprint.

Over time, this helps teams plan future work more realistically.

9. MVP

MVP is the most commonly used term in Agile.

And no, here MVP does not stand for Most Valuable Player. Instead, it stands for Minimum Viable Product.

An MVP is the simplest usable version of a product containing only the most important features.

Before ending this blog, there’s one important thing to understand — Agile is not as complicated as it looks at first.

Most beginners get confused because of all the technical terms they hear like sprints, backlogs, velocity, Scrum, and many more. But once you understand the core idea behind Agile, everything slowly starts making sense naturally.

At its very core, Agile is simply about building step by step, improving continuously, adapting to changes, and learning throughout the process instead of trying to make everything perfect at once.

Of course, Agile is a much bigger topic than what we covered here. Frameworks like Scrum, Kanban, estimation techniques, backlog management, and real-world Agile workflows go much deeper into how Agile actually works in teams and companies.

But as a beginner, understanding the thinking behind Agile is the most important first step. Once that becomes clear, the practical side of Agile — like how teams actually plan, manage, and deliver work during development — starts becoming much easier to understand as well.

And honestly, that's probably why Agile still makes so much sense in modern software development today.

AI Makes Us Faster. Agile Keeps Us Pointed in the Right Direction.

Wed, 20 May 2026 04:54:12 +0000

AI coding tools are changing the development loop.

With tools like Claude Code, Cursor, and GitHub Copilot, a solo developer can build screens, wire APIs, generate logic, and deploy much faster than before.

That is exciting.

But it also creates a new problem.

If we can build faster, we can also move in the wrong direction faster.

That is why I started thinking about Agile again.

Not as a set of meetings.
Not as Scrum rituals.
Not as a way to increase velocity.

But as a way to validate direction.

Speed does not replace direction

Before AI, implementation was often the bottleneck.

Even if a team knew what to build, actually building it took time. That slow process naturally created moments to think, question, and refine the direction.

Now the implementation loop is much faster.

You describe a screen, and code appears.
You describe an API, and endpoints are generated.
You describe a workflow, and an assistant can produce a working draft.

That speed is useful. But it can also hide a dangerous pattern.

You ship one feature, then immediately see the next one.
Then the next.
Then another.

Before asking whether the current feature actually solved a real problem, you are already building the next thing.

Fast completion is not the danger.
Fast certainty is.

Agile was never just about moving faster

Agile is often misunderstood as a fast development methodology.

Run sprints.
Do standups.
Track velocity.
Ship often.

But the deeper point of Agile is not speed.

It is feedback.

Build something small enough to test.
Show it to real users.
Observe what changes.
Adjust direction before the cost of being wrong becomes too high.

A sprint without feedback is just Waterfall with shorter cycles.

This matters even more in the AI era.

AI can accelerate the “build” part of the loop. But it does not automatically answer the more important questions:

Who is this for?
What problem does it solve?
Is this problem painful enough?
Did the user actually need this?
What did we learn after shipping?
Are we improving the product, or just adding more features?

Those questions still belong to people.

For solo developers and founders

This is especially important for solo developers and indie founders.

AI makes it easier to build an MVP in a day.

But an MVP is not just a smaller product.
It is a smaller piece of evidence.

A landing page can be an MVP.
A manual workflow can be an MVP.
Five user interviews can be an MVP.

The goal is not to prove that you can build something.
The goal is to test whether the problem is real.

For founders, Agile is less about team process and more about hypothesis validation:

Problem hypothesis
Customer hypothesis
Channel hypothesis
Pricing hypothesis
Retention hypothesis
Feature hypothesis

If the problem hypothesis is wrong, building more features will not save the product.

For teams using AI

In teams, AI can increase output quickly.

More tickets closed.
More pull requests opened.
More features shipped.

But more output does not always mean more product value.

A team can ship eight AI-assisted features in a sprint and still see no change in retention, activation, or user satisfaction.

That is why the Definition of Done also needs to evolve.

In the AI era, “done” should not only mean:

code reviewed
tests passed
deployed successfully

It should also ask:

Can the team explain the AI-generated code?
Does this feature solve a specific user problem?
Is there a way to observe whether it works?
Did we define what we expect to learn?
Will this change inform the next decision?

AI can help us build faster.
But direction still needs to be verified.

Agile as a direction validation loop

The way I now understand Agile is simple:

Question → Hypothesis → Build → Observe → Adjust

AI can accelerate Build.
It may also help with Observe.

But Question, Hypothesis, and Adjust still require human judgment.

That is where Agile still matters.

Not because teams need more rituals.
Not because every company needs Scrum.
Not because velocity should go up.

But because faster development makes wrong direction more expensive.

I wrote a longer Deep Dive on this idea here:

https://dechive.dev/en/deep-dive/ai-era-agile-verification

Why Your Story Points Feel Arbitrary (And How to Fix It)

Wed, 13 May 2026 15:55:00 +0000

This article was originally published on Medium.

I just feel it is "2", no, I think it is "3".

When I first came across story points, I always wondered how the "experienced" people on the team were calling out numbers so confidently. Now that I've become one of those "experienced" people — I realized I still didn't have a stronger framework for it. Like everyone else, I'd gone with gut feeling. Others would nod along, and sometimes we'd walk out with no real sense of why. All I knew was it should follow the Fibonacci series. Everyone had different intuitions, and the loudest voice — or the consensus — won.

So I tried to build a mental model for myself (not used by the team, yet), so I'd have something to point at when I picked a number. This is what I landed on after trying it on a couple of story-pointing sessions.

The four dimensions

Story points are supposed to capture how big the story would be, but the word "big" can pack in a lot of things, so I unpacked it into four things that I could actually measure:

Complexity — How hard is this to build? New tech, tricky logic, or big design decisions push this up.

Effort — How much work is there? A lot of small, easy changes across many files can still be Medium or High here, even if each change is trivial.

Uncertainty / Risk — How clear is the requirement? Open questions, unfamiliar parts of the system, or things that might surprise me mid-way add risk.

Dependencies — Does this depend on other teams or systems? This one is about waiting, not work. And waiting still inflates the point value. Every time the work unblocks, I have to re-page the state back into my head — and a story that crosses sprint boundaries carries its own cognitive overhead and spillover risk. Some people would argue dependencies shouldn't affect the size at all — they're not work, just calendar drag — but for me the cognitive overhead is real enough that they belong in the rubric.

For each, I rate Low, Medium, or High.

Rating guide

Dimension	Low	Medium	High
Complexity	Pattern we've done many times	Some design decisions needed	New tech, design-heavy, or novel problem
Effort	Single small change	Multiple changes, moderate scope	Many files / modules / large scope
Uncertainty / Risk	Requirement fully clear	Some open questions	Significant unknowns
Dependencies	None external	One known, manageable	Multiple, or blocked on another team

How I map ratings to points

Roughly, here's where I thought it made sense. Your numbers will probably differ once you've used this a few times — and they should.

Ratings	Points
All Low	1
One Medium, rest Low	2
Multiple Medium	3
One High	5
Multiple High	8
Mostly High	13

Do not be mechanical about this, it works now for me, can change in future.

Sanity check: if a story lands at 8 or 13, ask whether it should be split before you size it. Stories with several high-rated dimensions are usually epics in disguise.

How I actually use it

I rate each dimension in my head before I name a number. The dimensions are the work; the number is just the output.

The biggest thing I noticed isn't that I'm picking better numbers — it's that I can finally say why. Before, "5" was a feeling. Now I can trace it back: complexity High, dependencies Medium, the rest Low. Even if I don't share the breakdown out loud, having it in my head means I'm offering an estimate instead of a guess. And when I disagree with the room, I have something specific to point at — "I think it's a 5 because the unknowns here are bigger than they look" — instead of defending a number on instinct.

This is a starting point, not a strict formula. Override it when experience says otherwise. After a few sprints, look back at the stories that surprised you — were the surprises about complexity? Dependencies? Something else? Adjust the dimensions and the ratings to match what actually drives your estimation misses.

What this is not

This doesn't convert to hours, and it shouldn't be used to measure individual productivity.

The number isn't the point. The four-dimension conversation that produces it is.

Thank you for reading, suggestions are welcome.

Follow me on LinkedIn: Raj Kundalia

Snake Oil, Rituals, and Why We’re Wrong To Burn It All Down

Tue, 05 May 2026 09:12:47 +0000

The term “snake oil salesman” is often used to describe individuals who engage in deceptive marketing practices. Wild west characters like Clark Stanley advertised their snake oil as a wondrous cure-all remedy. But in 1916, the U.S. government’s Bureau of Chemistry tested the liniment, found it to be dramatically overpriced and of limited value, and Stanley was fined $20.

Yet that’s not the end of the story.

You Probably Use Snake Oil

Snake oil wasn’t entirely purposeless. While it’s true that it didn’t match the claims on the bottle, certain ingredients, such as capsaicin and camphor, proved valuable when used for valid purposes.

Capsaicin, derived from chili peppers, is now used in skin-applied pain relief products to relieve muscular and joint pain. It’s an FDA-approved therapeutic treatment. Camphor is also commonly used as a counter-irritant, helping relieve itching from insect bites. It’s also the go-to ingredient for makers of chest rubs, which you’ve likely used as a decongestant when you’ve had a cold.

So, while snake oil failed to match the wild claims of its peddlers, it wasn’t completely useless. This is also true in the software industry, so being able to separate the valuable ingredients from debunked software delivery recipes is a crucial skill.

Waterfall Is Bad, Mostly

The term “waterfall” is often used as a catch-all name for phased software delivery, where tasks are performed in a sequential order that resembles a waterfall. When the lightweight rebellion overthrew the heavyweight models of the time, it created a mistaken belief that the phased software models were simply wrong.

But the creators of these old models have been short-changed, as they had been telling us to work in this new way all along.

In his 1956 paper, “Production of Large Programs,” Herbert Benington discusses concepts that we would now label as platform engineering. Benington decried the idea of top-down programming, where a specification would be completed before the code was written. Winston Royce, in his 1970 paper “Managing the Development of Large Software Systems,” advised people to work in small incremental changes, as this would reduce complexity and allow organizations to roll back to a previous version if they moved in the wrong direction. These ideas resurfaced in Barry Boehm’s Spiral Model.

The success of Agile was largely due to how the proponents of lightweight software delivery carefully extracted the good ingredients from the heavyweight recipe used in the popular processes that dominated the industry in the 1990s. They preserved the good parts and discarded large swathes of the toxic ones.

The Recurring Crisis

Our crisis comes from a tendency for management to be attracted to process and repelled by technical and cultural practices. They have a craving to reintroduce elements of phased software models that were expertly removed, and they want to discard crucial techniques that they don’t understand (or sound like hard work).

Increasing process weight while decreasing technical excellence is a path to destruction.

The canonical example of this management error comes from the early days of Agile. Around the time of the Agile Manifesto, the leading lightweight method was Extreme Programming (XP). It had similar process elements to Scrum, but also a map of interconnected technical practices that kept the cost of change low, which is the key to sustaining agility over the long term.

For managers, Scrum’s exclusive focus on process was unthreatening, while XP’s emphasis on technical skills struck fear into their hearts. When it came to management, Scrum was top dog. As a result, we spent a decade spinning wheels until Dave Farley and Jez Humble revived and renewed the ideas of XP in their landmark book, “Continuous Delivery.”

Of course, it didn’t stop with Scrum. When you don’t have technical excellence, the process elements of Scrum don’t deliver the outcomes that are expected of agile software development. As a result, management responded by bulking up the process to “work at scale” or “handle Enterprise needs”. The real motivation behind this was, of course, the comfort of process working against the complexity of reality, which can only be resolved by social and technical means.

When DevOps first emerged, it could be summed up as breaking down the silos between development and operations. This idea was further refined to align the goals of the two teams and encourage them to collaborate more effectively. Everyone was on board with this until a decade of research revealed the need for those intimidating technical elements, the necessity of transformational leadership, and the value of lean product management. When DevOps got too real, the desire to run away intensified.

The rush from complex realities to simplifications is a mistake we repeatedly make. Putting it unkindly, the fall of all good methods is the result of managers fleeing in terror from things they don’t understand as well as they should.

Finding The Real Remedy

The software industry’s snake oil problem isn’t that we have too many frameworks and practices; it’s that we have too few. It’s that we’ve lost the ability to think critically about them. We adopt wholesale when we should cherry-pick. We follow prescriptions when we should experiment.

The most effective software teams aren’t the ones who’ve found the perfect framework. They’re the ones who’ve learned to extract value from imperfect ones, who understand that every practice is context-dependent, and who continuously question whether what they’re doing is actually helping.

Snake oil taught us an important lesson, but it wasn’t the one we thought. It’s not that old remedies are worthless. It’s that we need to look past the marketing to understand what actually works. The same applies to software practices. Behind every framework, methodology, and best practice lies a kernel of insight that addresses a real problem.

Our job isn’t to mindlessly follow or unthinkingly reject. It’s about understanding, extracting, and applying wisely.

I Built a Benchmark That Proves Most LLM Agents Are Statistically Blind And Why That Costs Companies Real Money

Mon, 27 Apr 2026 08:08:58 +0000

RealDataAgentBench forces agents to think like actual data scientists, not just copy answers. Here’s what I learned after running 163 experiments across 10 models.

Two months ago I got tired of watching LLM agents ace toy benchmarks but fall apart on real data science work.They could write code. They could get the final number right.

But when it came to statistical validity proper uncertainty reporting, avoiding data leakage, understanding confounding variables, or choosing the right method they were guessing.

So I built RealDataAgentBench.

It is not another “does the model get the right answer?” benchmark.

It is a test track that grades LLM agents on four dimensions that actually matter in production:

Correctness - does it match ground truth?
Code Quality - is the code vectorized, readable, and professional?
Efficiency – how many tokens and dollars does it burn?
Statistical Validity – does it think like a careful statistician or just hallucinate confidence?

Every task uses fully reproducible seeded datasets. Every run is scored automatically. The leaderboard updates itself via GitHub Actions.

I currently have 23 tasks across EDA, Feature Engineering, Modeling, Statistical Inference, and ML Engineering. I have run 163+ experiments across 10 models (Claude Sonnet, GPT-4o, GPT-4o-mini, Grok models, Gemini 2.5, Llama via Groq, and more).

Some results surprised me:

GPT-4o and Claude Sonnet are extremely close in overall score.
GPT-4o is dramatically cheaper per task.
Groq Llama models are fast and cheap but sometimes skip statistical rigor.
The biggest failures are not in correctness they are in statistical validity and code quality.

That is expensive for companies. Choosing the wrong model can easily waste thousands of dollars per month in API costs and produce analyses that look correct but are statistically flawed.How the benchmark actually works (real example.

Take task eda_003 — E-Commerce Confounding Variable Detection (Hard).

The agent is given sales data that exhibits Simpson’s Paradox. It must detect the confounding variable, compute partial correlation, and explain the result correctly.

Most agents fail here. They report the aggregate correlation and confidently declare “positive relationship” while completely missing the reversal when you control for the confounder. My scoring engine catches that instantly in the Statistical Validity dimension.

The agent also has to write clean, vectorized code and stay within the token budget.This single task reveals more about a model’s real capability than 50 simple math questions.

Why this matters for companies

Small and medium companies cannot afford to test 10 different models manually. RealDataAgentBench lets them drop their own dataset in and get an immediate recommendation:

“Use GPT-4o for this data best statistical validity at 60% lower cost than Claude Opus.”I added a budget flag so even tiny teams can test safely without surprise bills. Groq support makes the first tests completely free.

What I learned building it

Different models need different system prompts.
Claude loves strict instructions; Grok is creative but lazy on stats.
Reproducible seeded datasets are non-negotiable for fair comparison.
The hardest part was not the code it was making the scoring engine statistically honest.

Open-source done right (clean README, Makefile, .env.example, proper CI) gets you real contributors and stars.

The project is 100% open source:
→ https://github.com/patibandlavenkatamanideep/RealDataAgentBench

leaderboard: https://patibandlavenkatamanideep.github.io/RealDataAgentBench/

Try it yourself in under 5 minutes:bash

- git clone https://github.com/patibandlavenkatamanideep/RealDataAgentBench
- cd RealDataAgentBench
- pip install -e ".[dev]"
- cp .env.example .env
- dab run eda_001 --model groq --budget 0.05

If you work with data and LLMs, I would love your feedback. Star the repo, open an issue for a new task you want, or tell me which model surprised you the most.

This is just the beginning. I am actively expanding the task suite and adding more enterprise features.

What real data-science failure have you seen LLMs make lately? Drop it in the comments I might turn it into the next task.

SprintPulse

Sun, 25 Jan 2026 06:02:08 +0000

What are retrospectives and why do they matter?

A retrospective is a structured team meeting - typically held at the end of a project, sprint, or work cycle - where everyone reflects on what went well, what could have gone better, and what to try differently next time. It sounds simple, but done consistently, retrospectives are the single most effective practice for building teams that continuously improve. They create space for honest feedback, surface problems before they become crises, and give every team member a voice in shaping how work gets done. Research consistently shows that teams who run regular retrospectives ship better products, have higher morale, and retain talent longer - because people want to work somewhere their input actually matters.

Why I built SprintPulse

Despite their proven value, most retrospectives fail to deliver. Feedback gets scribbled on sticky notes and forgotten. The same issues come up sprint after sprint with no resolution. Action items are assigned but never tracked. Enterprise tools promise solutions but cost a fortune and come bloated with features no small team needs. I built SprintPulse because I was tired of running retrospectives that felt productive in the moment but led nowhere. I wanted a tool that would capture honest feedback, surface real priorities, and - most importantly - ensure follow-through. Something designed for teams that actually ship, not committees that meet.

How SprintPulse makes retrospectives actually work

SprintPulse combines a clean, modern interface with genuinely useful AI features. Anonymous submissions create psychological safety so people say what they really think. Real-time collaboration means everyone participates simultaneously - no waiting turns, no lost momentum. Live voting surfaces the issues the team truly cares about, not just whoever speaks loudest. The AI is woven throughout the workflow: it suggests merging similar feedback so you are not discussing the same point three times, generates polished summaries the moment you finish, proposes concrete action items based on your actual discussion, and tracks recurring topics across retrospectives to spot patterns you would otherwise miss. Sentiment analysis shows how team morale trends over time, giving you early warning signs when something is off.

Give your team the retrospective experience they deserve

The difference between a useful retrospective and a forgettable one is follow-through. SprintPulse assigns action items to specific people with real deadlines, tracks them across sprints, and surfaces them at the start of each new session so nothing falls through the cracks. One-click exports send summaries straight to Slack or stakeholder inboxes without manual copy-pasting. All of this runs on EU-hosted infrastructure with GDPR compliance, at pricing designed for real teams - not enterprise budgets. If you have ever walked out of a retrospective knowing good ideas were shared but doubting anything would change, SprintPulse is built for you. Give your team a tool that turns reflection into results, and watch what happens when honest feedback actually leads somewhere.

Micro-Frontends: What They Are and Why You Should Use Them

Mon, 19 Jan 2026 21:01:26 +0000

In this continuing hackathon coverage article, we explore how the team is progressing in building an AI-powered travel agent app using micro-frontends, Module Federation, and other modern tools!

About The Hackathon

This hackathon, hosted by Shashi Lo’s Gridiron Survivor apprenticeship program, brings together developers for a fast-paced challenge: building an AI-powered travel app entirely from scratch. Taking place in the first quarter of 2026, two rival teams are competing, with each group working on their own unique project. The event offers not only prizes, but also a great opportunity to build skills, collaborate in a real-world setting, and share progress with the community. While there’s a competitive edge, the main focus is on learning, teamwork, and gaining hands-on development experience.

To follow our journey, ask questions, and share your feedback in real time, subscribe to the Coding with Shashi YouTube channel and turn on notifications to stay updated on all the latest events.

Hackathon/Gridiron Survivor Team Members:

Alex Appleget
Cody Epstein
Hector Suazo
Will Cooley
Dominic J. Monaco
Jennifer Tieu
David Terzano
Michael Larocca
Tony Briely
Aman Lokhande
Bradley Diep
Parys G Khazaie
Kerilne Moncy
Calypso Hernandez MFA CSM
Jeremy Fischer
Mike Chen
Nicktaylor
Shashi Lo

What Are Micro-Frontends

Micro-frontends are a way of building a large website by breaking it into smaller, independent sections—each one like its own mini-app, often managed by different teams. Instead of everyone working in one giant codebase, each section focuses on a specific feature, such as search, a shopping cart, or your profile. Teams can build, update, and deploy their own part without waiting for everyone else, using the tools and frameworks they prefer. When you visit the site, a main app brings all these pieces together, so everything feels like one smooth, unified website.

Why Use Micro-Frontends

Why use micro-frontends? As websites grow more complex, it becomes harder for teams to work together in the same codebase without things getting overwhelming. Micro-frontends make it easy to split up the work so teams can focus on just their part of the site. This means updates and new features can go live faster, since teams aren’t waiting on each other. It’s also easier to find and fix problems because everything is broken down into smaller, more manageable pieces. Plus, teams get the freedom to choose the best tools for their section, making everyone’s job simpler and more enjoyable. In the end, micro-frontends help teams move quickly, stay organized, and keep big websites running smoothly.

What Is Module Federation

Module Federation is a tool that lets different parts of a website—like micro-frontends—share code and features with each other, even if they’re built and deployed separately. Think of it like connecting LEGO sets: each team can build their own section of the site, but Module Federation makes it possible to snap those pieces together and even share special bricks (like buttons or menus) without having to copy them everywhere.

With Module Federation, teams can update or add features to their section without affecting the rest of the site. It also means they can use the same tools or libraries just once, instead of loading multiple copies—keeping things fast and efficient. For micro-frontends, this is a game-changer: it allows true independence for teams, while still making sure everything works together smoothly for users. In short, Module Federation is the magic that helps all the mini-apps "talk" to each other and play nicely as one big app.

Personal Reflection

Micro-frontends and Module Federation work together to let teams build complex apps in a smarter, more flexible way. For our hackathon project, this meant we could split our travel app into separate sections—each with its own team and features—while still keeping everything connected. Module Federation was the glue that let us share code and release updates independently, without breaking the rest of the app.

Getting hands-on with these tools during the hackathon showed me just how practical and powerful this approach is. Here’s what I discovered:

At first, I did not grasp the concept or understand the benefits of a micro-frontend—it just sounded like standard React to me, where components can be worked on separately by team members. The “Team Champs” divided their TripWeave app into three parts: Pre-Trip, Itinerary, and During Trip, and each part is set up as a micro-frontend.

With this micro-frontend approach, each part of the app can be worked on independently, without launching the entire app. This allows for a streamlined development process that benefits the team as a whole. For example, the “During Trip” part of the app—an AI-powered travel assistant—is being worked on independently and can even be launched on its own, without having to launch the entire app.

Micro-frontends also let teams share things like components or helper functions, so you don’t have to copy and paste the same code everywhere. This helps keep things simple and follows the “Don’t Repeat Yourself” (DRY) principle. The Module Federation tool works alongside micro-frontends to make this kind of sharing possible, so teams can work independently and still use each other's code when needed.

Here are a few more things I learned along the way:

Incremental Adoption: You don’t have to switch to micro-frontends all at once—just add them piece by piece.
Independent Releases: Teams can deploy updates to their micro-frontend whenever they’re ready, without waiting for the entire app to be finished.
Consistent User Experience: It’s important for the entire team to work together on things like design and navigation, so the app still feels seamless for users, even though different teams built different parts.

Overall, learning about micro-frontends opened my eyes to new ways teams can build better apps together. This was my first experience working with micro-frontends, and although it was admittedly a bit challenging to grasp and set up, I now see the value and benefits they bring to team-based projects.

Team Champs TripWeave app in progress

How We Use Micro-Frontends in the Hackathon

For the Trip-Weave hackathon project, as previously mentioned, one team of 10 members took on the challenge of building the app. This team was further divided into smaller groups, with each group responsible for one section: Pre-Trip, Itinerary, or During Trip (with a few senior members supporting all three micro-frontends). This setup made it much easier for the groups to build, test, and update their section independently, without worrying about breaking the rest of the app.

To organize and connect all the pieces, the team used a tool called Rsbuild. Rsbuild is a super-fast build tool—think of it as a high-speed publisher for your app—that turns code into something the browser can use. Each micro-frontend had its own setup, so groups could work independently and development was much faster. The main app, called the "shell," could then pull in each micro-frontend on demand, similar to plugging in different game cartridges. Rsbuild was chosen because it's fast, supports sharing key libraries like React as singletons (so only one copy runs at a time), and works well with the team's deployment setup.

To help everything work smoothly together, Module Federation was also used. This allowed the team to share code and features between sections, so there was no need to copy and paste the same things everywhere. Zephyr (one of this Hackathon’s sponsors) was also brought in to help automatically check and share code safely between the groups, making collaboration even easier. Zephyr is a platform and set of tools that helps deploy, manage, and connect micro-frontends in the cloud. It also helps generate TypeScript types for shared code, making sure everything fits together and reducing mistakes. In addition, Zephyr was used to deploy the app to the cloud, streamlining the launch process for the entire team.

Gridiron Survivor Hackathon & Zephyr Cloud

This video introduces the Gridiron Survivor’s Hackathon, sponsored by Zephyr Cloud, with a focus on AI and building specialized agents. Zach Chapel, CEO and co-founder of Zephyr Cloud, discusses the launch of Zephyr Agency—a platform designed to create powerful, purpose-driven AI agents that go beyond generic tools.

Highlights from the video:

Specialized AI Agents: The benefits of building agents with specific skills and human-like attributes, making them more effective than generalist AIs.
Hackathon Project Ideas: Potential projects include travel agents or websites using these specialized agents to provide tailored experiences.
Micro-Frontends & Module Federation: How breaking apps into smaller, independent pieces lets teams work faster and deliver a seamless user experience. Zephyr Cloud streamlines this process with efficient deployment tools.
Junior Developers & AI: The value of junior developers who are eager to learn and adopt new AI technologies, often adapting faster than more experienced developers.

Watch the video to learn more about how AI and modern web development tools are shaping the future of collaborative projects!

Further Learning

For an in-depth dive into Micro-Frontends, check out Jack Herrington’s excellent freeCodeCamp YouTube course: Micro Frontends Course – Beginner to Expert

This course covers foundational concepts and advanced techniques, making it a great resource for both beginners and experienced devs!

Gridiron Survivor Sponsors

A very special thanks to our sponsors!

GitKraken: A popular Git client that provides a graphical interface to manage Git repositories. It is known for its user-friendly design and features that simplify version control, making it easier for developers to collaborate and manage their code.
Frontend Mentor: An online platform that offers front-end coding challenges. It helps developers improve their skills by providing real-world projects to work on and a supportive community for feedback and learning.
Zephyr Cloud: A Module Federation platform that accelerates micro-frontend development by providing instant deployment, intelligent dependency resolution, and seamless version management—all while remaining cloud agnostic, framework agnostic, and bundler agnostic.

Be sure to listen to the HTML All The Things Podcast!

???? I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Torc is an AI-powered platform and vibrant global network that connects skilled professionals with top opportunities and forward-thinking companies. If you’re interested in joining, you can create a free profile using my referral link: https://platform.torc.dev/#/r/b5QZ7k5h/cp

Affiliate & Discount Links!

With CodeMonkey, learning can be all fun and games! CodeMonkey transforms education into an engaging experience, enabling children to evolve from tech consumers to creators. Use CodeMonkey's FREE trial to unlock the incredible potential of young tech creators!

With a structured learning path tailored for various age groups, kids progress from block coding to more advanced topics like data science and artificial intelligence, using languages such as CoffeeScript and Python. The platform includes features for parents and teachers to track progress, making integrating coding into home and classroom settings easy.

Through fun games, hands-on projects, and community interaction, CodeMonkey helps young learners build teamwork skills and receive recognition for their achievements. It fosters a love for coding and prepares children for future career opportunities in an ever-evolving tech landscape.

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Become a hireable developer with Scrimba Pro! Discover a world of coding knowledge with full access to all courses, hands-on projects, and a vibrant community. You can read my article to learn more about my exceptional experiences with Scrimba and how it helps many become confident, well-prepared web developers!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Instead of building one giant website, micro-frontends let teams split the project into smaller, independent sections, almost like mini-apps. Each team can focus on specific features and work in parallel. This approach makes big projects easier to manage, speeds up updates, and helps teams avoid stepping on each other’s toes. It also allows for more flexibility and a smoother user experience.

Module Federation is the secret sauce that lets these separate parts share code and work together seamlessly, even if they’re built and deployed independently.

Working hands-on with micro-frontends and Module Federation during the hackathon changed the way I think about building apps. I saw firsthand how these tools help teams collaborate, experiment, and release updates faster, all while keeping everything organized and connected. Whether you’re building a big project with a team or just curious about new ways to structure your apps, these tools are definitely worth a look!

Let’s connect! I’m active on LinkedIn and Twitter.

Why you should adopt Continuous Delivery

Mon, 24 Nov 2025 15:38:06 +0000

Continuous Delivery (CD) often requires significant up-front investment and it takes time to create a high-performance deployment pipeline. You need to put tools in place to maximize the impact of Continuous Delivery on your software delivery performance. At times, it might seem like it’s too difficult without enough tangible benefits.

On this page we explain why you should adopt Continuous Delivery, the pain it removes, and the concrete benefits you can expect in return. We show you a:

Reinvestment strategy you can use to create a self-funding continuous improvement budget
Model that shows you’re likely to make the returns faster than you might think

Reasons to adopt Continuous Delivery

Here are some common scenarios that cause friction for teams. Building the team’s Continuous Delivery skills will help remove this friction.

Painful deployments

You’re not alone if your deployment process causes a sense of fear or anxiety. There are many signs your deployments are more challenging than they should be:

Manual deployments: You follow a checklist or document to perform the deployment, and sometimes miss steps or perform them out of order.
Long deployments: Your deployment process takes more than a couple of minutes, sometimes hours.
Out-of-hours deployments: Your deployments must happen during unsociable hours and sometimes take all night.
Infrequent deployments: You only deploy once a month, quarter, or even less frequently.
Change freezes: You can’t deploy during the peak season, usually because of a past blow up.

Repeatable, reliable, and predictable deployments remove this pain, helping you focus on making the best software you can, without dreading deployment time.

Painful onboarding

When new developers join a team, they can feel accomplishment and relief by making their first change to an application. If they can’t start quickly by getting the latest version of the code from source control, the day-one nerves continue until they feel productive.

Some signs that your onboarding is painful include:

Needing to install tools, frameworks, and dependencies on their local machine
Having to check out and run other services locally that your application depends on
Needing to restore a database locally that contains test data, or sharing a development database that keeps changing
Needing to update the version-controlled config files to reflect their local environment
Waiting for weeks or months for their first change to go live

Painful pre-live environments

Pre-live environments often present several kinds of pain. There’s often contention over who uses an environment at any given time, and they can often be very different to production infrastructure.

For example, it’s common to find applications designed to scale horizontally, with many instances of the application deployed to handle the load. If the pre-live environment doesn’t represent this, there are whole classes of faults you can’t detect until you go live.

Testers often find they can’t use a new software version due to a critical issue, like the sign-in page not working. They sometimes have to wait in a queue for an environment or get surprised by a new version of the software that another tester deployed while they were still testing a previous version.

Making it possible for testers to pull a version of the software on-demand to a temporary environment created only for their use is a much better solution.

Painful batches of work

Often made worse by infrequent deployments, batches of work can quickly become painful as good changes get stuck when they’re in the same software version as bad changes.

If you continue to add changes while you wait for fixes, you often add a new bad change while resolving a previous one. This usually gets so bad the organization declares a change freeze where developers can only fix those bugs.

One sign of painful batches is a list of known faults arranged into categories. These show whether they’ll get fixed before the software deploys.

A better approach is for each change to the software to create a new version. The new version flows through the deployment pipeline independently, making it possible to fix issues for a single change when detected.

Painful operations

Operations tasks tend to become painful over time. Configuring infrastructure might be easy initially, but keeping the configuration in sync across environments and services becomes more challenging as things scale. The application architecture may become more complex as the organization grows, making it difficult to understand the impact of infrastructure changes.

You can detect operations pain by looking for signs like:

Manual changes to infrastructure either by accessing machines directly or through web portals (often called ClickOps)
Problems managing configuration and configuration drift
Bugs caused by subtle configuration differences between environments or instances
Infrastructure changes take a long time, as you need to repeat them many times
No way to roll back to a previous infrastructure configuration
Emergency changes to resolve a live issue, followed by wondering which of many speculative changes fixed the fault

A better approach is to version control infrastructure and configuration the same way you control software versions. That way you can quickly review changes and automatically deploy specific versions.

Painful process

Often caused by other pains, things can go terribly wrong in software delivery. A common reaction to past hurt is to introduce bureaucratic stages to prevent the problems happening again. Change freezes, sign-offs, and advance deployment scheduling are all signs someone tried to reduce other sources of pain.

The problem is these interventions bloat processes without improving software delivery performance. Any stage that delays software releases tends to increase the batch size of the deployment, making it more likely things will go wrong.

Benefits of Continuous Delivery

Continuous Delivery solves these common software delivery pains. By building a deployment pipeline with an appropriate set of tools and automation, you can create a release process that’s repeatable, reliable, and predictable.

You can make work easier and more fulfilling across all roles involved in software delivery.

Alongside the reduction of pain, there are also several benefits.

Human benefits

There’s far less stress once a solid deployment pipeline and related practices are in place. Deployments no longer create widespread anxiety, and the organization has confidence the team can deliver software safely and reliably.

Frequent high-quality releases are the best way to increase trust between development, operations, and the rest of the business.

When deployments are no big deal, everyone can relax and focus on doing their best work.

Software delivery benefits

In terms of software delivery, the lead time for changes will be shorter. You can deliver features and bug fixes sooner. You have fewer merge conflicts, and small batch sizes will stop changes cyclically blocking each other.

Automation reduces configuration and deployment errors. Your deployment automation ensures the correct code version deploys using the proper process. You miss no steps and those you perform have no errors, and your infrastructure will be in the right state.

You can handle issues by creating an environment with the suspect software version to recreate the problem quickly.

Learn more in our detailed guide to Continuous Delivery tools.

Business benefits

Continuous Delivery provides tangible business benefits, with organizations using the tools and practices:

2x more likely to meet or exceed commercial goals
2x more likely to meet or exceed non-commercial goals
2.2x more likely to be recommended as a good place to work
Growing their market cap 50% higher

Press enter or click to view image in full size

Teams using Continuous Delivery spend more time on features and less time on bug fixes. They deploy more often, and their software is more reliable.

Challenges of adopting Continuous Delivery

Adopting Continuous Delivery provides both technical and cultural challenges. Both are equally important. You may also want to form a strategy for how you invest in the work needed to build the deployment pipeline.

Technical challenges

Although you will likely already some necessary tools, you need to identify gaps. Get the missing tools and related skills to create a reliable and automated deployment pipeline.

Most teams have version control and a build server, but you may need to use the more advanced features of these tools to test and package the software. You need to look at artifact repositories, deployment automation, infrastructure automation, and monitoring and alerting.

As well as tools, the technical practices of Continuous Integration, test automation, architecture, security, and observability may represent areas you need to strengthen.

Cultural challenges

You may need to make cultural challenges. If your operations team is at arm’s length from your development team, you need to resolve some classic development and operations conflicts so the teams can work together on Continuous Delivery. Culture is one of the critical capabilities of DevOps, and there’s plenty of evidence that links positive culture to actual business outcomes.

For example, if your ops team won’t allow automated deployments to the production infrastructure, you’re unlikely to get the full benefit of Continuous Delivery. You still get some benefits, like automated on-demand deployments to other environments, but you find the live deployments remain difficult and infrequent.

You could avoid this challenge by proving the benefits to stakeholders in pre-live environments, but the operations team will likely see this as a move to undermine them. Instead, collaborate with the operations team and take the time to build trust.

It’s best to tackle cultural issues head-on as early as possible.

An investment strategy

The main challenge is investing the time into building your deployment pipeline. You will gain this time back quickly as you reduce the manual effort involved in deployments. We recommend a reinvestment model to resolve this challenge.

Invest a fixed amount of time in automating one part of your deployment pipeline. Use the time saved by this automation to create a weekly budget for further automation.

Each time you automate another part of your Continuous Delivery pipeline, you create more time in your automation budget. This limits the spending to whatever fixed period you originally invested.

Cost-benefit analysis of Continuous Delivery

Google Cloud, along with DevOps Research and Assessment (DORA), created a model for investment in DevOps transformation. By accounting for several factors across business sizes, their model demonstrated that it’s possible to pay back investment within a month of completing the transformation. The total return can be ten times the original investment.

With this in mind, you may want to accelerate your investment in building your deployment pipeline and adopting Continuous Delivery practices. These are key DevOps capabilities.

Summary

Continuous Delivery removes a great deal of pain from your software delivery process. Along with other DevOps practices, it can bring high-impact benefits, not just for your software but for your whole organization.

Git Basics: A Beginner's Guide to Branches

Tue, 11 Nov 2025 21:49:11 +0000

This article explores Git branches and their role in version control. You'll learn about team practices of creating, merging, and managing branches, gaining essential skills for collaborative projects!

What is Version Control?

Version control is a system that helps track changes to files over time. It allows multiple people to collaborate on a project, keeping a history of modifications, so you can revert to previous versions if needed. This is especially useful in software development, where teams collaborate on code, ensuring everyone is on the same page and changes are managed efficiently.

What are Git Branches?

In the context of version control, Git branches are like separate workspaces within a project. They allow you to work on different features or fixes without affecting the main codebase. Each branch can be developed independently, and once the work is complete, it can be merged back into the main branch. This system enables teams to collaborate efficiently, allowing multiple people to work on different tasks simultaneously without interfering with each other's work.

Merge Develop into the Master Branch

When working alone, you'll likely build your projects directly on the default master (main) branch. Even when you start to create individual branches, they will be made from the master branch and be merged back into it. However, when working on a team project, there is usually a development (develop) branch in addition to the master branch, and it is vital to understand how to work with them.

In my recent experience, when implementing a professional Agile workflow in my personal project, I finally understood the concept of having both a develop and master branch. Now that I was creating individual branches for each of my issues, each time I pushed to the default master branch, a deployment was triggered (though Netlify). So I initially thought, “Why am I bothering to make new branches, since I am not working in isolation?” Then I realized that is precisely what the develop branch is for. The purpose of the develop branch is to serve as an integration branch for features before they are ready for production.

In a team-based environment, once you have finished working on your individual issue branch, push and merge it into the develop branch (not the master branch). When all the individual issue branches are merged into the develop branch, yours and presumably those of fellow team members, it is the “develop branch” that gets merged into the “master branch,” which will then trigger a deployment if configured to do so. The master branch is typically the production-ready branch, which is why merging into it triggers deployment.

By following this workflow, you and other team members can confidently work on your own individual branches, contributing to the project simultaneously. Then, when all of the branches are accepted and merged into the develop branch, the team’s work will be deployed to the project once the develop branch is merged into the master branch.

Note: When working on issue branches, it is essential to follow a team-based Agile workflow, which includes testing and code review to ensure quality before merging them into the develop branch.

Make Your Issue Branch from Develop

As I am sure you know, it's crucial to pull all changes from the remote branches first to ensure all files are updated with the latest versions. If you've been working alone for a long time, it might take some time to get used to pulling changes first.

When working on a team project, you'll need to create branches to address individual issues. Generally, these issue branches are created from the develop branch rather than the master branch. So, be sure that you clarify with your team which branch to use as the base for your issue branches.

Note: To maintain consistency and avoid conflicts, it's essential to pull changes from both the master and develop branches regularly. This practice ensures that your branch is synchronized with the latest updates from the main codebase and the develop branch. By doing so, you minimize the risk of merge conflicts and ensure a smoother integration process when your work is ready to be merged back into the main branches.

Agile Development

Having covered the overall concept of working with branches, it's important to note that there are specific conventions and workflows for creating them. These conventions are often guided by Agile development principles, which emphasize flexibility, collaboration, and iterative progress in software projects —principles that my team follows.

Members of the Gridiron Survivor apprenticeship program, of which I am a part, work on individual issue branches of our current project, Elfgorithm, a Secret Santa-style gift exchange app. We use naming conventions for the branches and organize our work into Sprints, which are time-boxed periods during which specific tasks or features are developed. Each individual issue branch undergoes review and testing to ensure quality and functionality.

The naming conventions we use for branches include the programmer’s name, issue number, type (the kind of work), and a short description of the branch’s purpose:

\[YourName\]/\[IssueNumber\]-\[type\]-\[IssueDescription\]

Using naming conventions for branches enhances project organization and efficiency, allowing branches to be quickly identified and facilitating collaboration.

These conventions also improve Git automation. Scripts can recognize branch patterns to trigger actions, such as tests or notifications, resulting in reduced manual effort and ensuring consistency. Linking Sprint ticket numbers to issue branches connects the code to project management tools, simplifying progress tracking and aligning work with tasks.

Overall, structured naming conventions improve organization, communication, and workflow efficiency in software development.

Deleting with an Individual Issue Branch

Once your individual issue branch is accepted and merged into the develop, it is then safe to delete it. GitHub provides a “Delete Branch“ button for easy removal on the remote repository. You will also need to delete your issue branch in your local repository.

Once your issue branch is deleted from both the remote and local repositories, remember to pull the changes from the master and the newly merged develop branch. This ensures your local repository is up-to-date with the latest changes. Afterward, you can use git fetch --prune to clean up your local repository by removing any remote-tracking references that no longer exist on the remote.

Merge Conflicts

Dealing with merge conflicts deserves its own article, but it’s important to understand, so I will provide a brief overview.

A merge conflict occurs when Git is unable to resolve differences in code between two branches automatically. This typically happens when two team members make changes to the same part of a file. For example, imagine two team members both update the README file and change the same line. Git doesn't know which change to keep, so it flags this as a conflict.

To fix a merge conflict, you'll need to manually review the conflicting changes and decide which version to keep. Here's a simple way to handle it:

Identify the Conflict: When you try to merge, Git will notify you of the conflict and mark the conflicting areas in the file. You'll see markers like <<<<<<<, =======, and >>>>>>> indicating the different changes.
Resolve the Conflict: Open the file in a text editor and look for these markers. Decide which changes to keep or if you need to combine them. Remove the markers and ensure the file appears as you want it to.
Mark as Resolved: Once you've resolved the conflict, save the file and use git add <file> to mark it as resolved.
Complete the Merge: Finally, commit the changes with git commit to complete the merge process.

By understanding and resolving merge conflicts, you ensure that your team's work is integrated smoothly and accurately!

About Us

What is Gridiron Survivor?

Gridiron Survivor is an apprenticeship program created by Shashi Lo, a Senior UX Engineer at Microsoft. It aims to provide developers entering the tech industry with vital work experience. The program focuses on practical training in project management, coding practices, and team collaboration, offering mentorship and skills essential for success in their initial tech roles.

What is the Elfgorithm App?

Elfgorithm is an AI-driven Secret Santa app set to launch in winter 2025. It streamlines gift exchanges by removing the guesswork from Secret Santa activities. The app manages gift-giving details and provides personalized gift suggestions, ensuring you find the perfect presents for everyone.

Gridiron Survivor Sponsors

A very special thanks to our sponsors!

GitKraken: A popular Git client that provides a graphical interface to manage Git repositories. It is known for its user-friendly design and features that simplify version control, making it easier for developers to collaborate and manage their code.
Frontend Mentor: An online platform that offers front-end coding challenges. It helps developers improve their skills by providing real-world projects to work on, along with a supportive community for feedback and learning.
Vercel: A cloud platform for static sites and serverless functions. It is designed to optimize the workflow of developers by providing tools for building, deploying, and scaling modern web applications with ease. Vercel is known for its seamless integration with frameworks like Next.js.

Be sure to listen to the HTML All The Things Podcast!

I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Version control is a system that tracks changes to files over time, enabling multiple people to collaborate on a project and revert to previous versions if necessary. In development, branches provide separate workspaces within a project, enabling the independent development of features or fixes without affecting the main codebase. In a team project, there are typically both a development branch and a master branch. The team works on the development branch, which is eventually merged into the master branch.

Individual issue branches are created from the development branch. Once a team member completes an issue branch, it undergoes review and testing as part of Agile development practices before being merged back into the development branch. These issue branches are deleted from both the remote and local repositories after they are merged to maintain a clean codebase.

When working with a team, merge conflicts happen when multiple developers change the same part of a file in different branches. You need to manually resolve these conflicts by reviewing the changes, deciding which ones to keep, and removing the conflict markers. Handling merge conflicts effectively is crucial for maintaining a smooth workflow and ensuring the accurate integration of team members' work.

Practicing is the best way to learn! Even if you're working solo, you can apply Agile workflows to your personal projects by creating, merging, and managing branches. This approach will help you develop marketable skills as you learn and implement Agile workflows!

Let’s connect! I’m active on LinkedIn and Twitter.

Sprint Workflow: A Beginner's Guide to Agile Development

Tue, 28 Oct 2025 09:33:28 +0000

In this article, we explore the sprint process in software development. You'll learn to manage tasks using a sprint board, track progress, and enhance team efficiency for successful project deliveries!

What Is a Sprint?

A sprint is a short, focused period of work during which a development team tackles specific tasks or goals (for my team, it’s two-week periods). In modern software projects, sprints help teams stay organized, track progress, and deliver updates efficiently.

What is Agile Development

Agile development is a way of building software that focuses on flexibility, teamwork, and continuous improvement. Instead of planning everything up front, teams work in short sprints to deliver small, usable project pieces. After each sprint, the team reviews what went well and what can be improved, making it easier to adapt to changes and deliver better results. Agile helps teams stay organized, respond quickly to feedback, and progress projects.

What is a Sprint Board & Ticket?

I like explaining a ticket by analogy—think of a ticket as an index card pinned to a corkboard (Sprint Board). In the following example, the corkboard has five column headers labeled as follows:

To Do
In Progress
In Review
Testing
Done

The index card lists tasks and moves through each column of the corkboard as the tasks are completed.

To Do	In Progress	In Review	Testing	Done
(TICKET)

To Do

Let’s write two tasks on the imagined index card:

Update the README file to include the new login feature
Add a URL link to the deployed project.

The provided index card (sprint ticket) will have an auto-generated number; let’s say it’s 12.

Now, I will assign YOU to complete ticket number 12. After reviewing the assigned tasks, you will let the team know how long it will take you to complete. This is done using a point system.

A point represents a time variable that can differ among teams. Our team’s point system is as follows:

point-0: within 2 hours
point-1: within 1/2 day
point-3: within 1 day
point-5: within 3 days
point-8: within 1 week

Since this is your first ticket, a full day will be acceptable for the task as you will need time to write documentation for the new login procedure and add a URL to the project. Therefore, you should mark your ticket with 3 points (which represents a day).

In Progress

Once you start working on your assigned ticket, you move it to the “In Progress“ column. When you complete it, you move it to the “In Review“ column and notify your team.

In Review

The review phase of your ticket involves an assigned team member reviewing it to ensure that all of the assigned tasks were completed. In this demonstration, you needed to write documentation in the README file detailing the new login procedure and adding a URL to the project.

⚠ Important: You are NOT to go beyond the tasks on your ticket! For example, you would not add additional information to the README file regarding other aspects of the project. Although your intentions are good, since it goes beyond the scope of the ticket, it will be refused because it will cause confusion and disorganization. Further README file updates should be added to new future tickets.

Testing

Once the ticket passes the review stage, it is moved to testing to ensure the code functions properly; in this simple example, the project link must be clickable and direct to the correct URL. If your ticket passes the testing phase, it is closed and moved to the “Done“ column.

Done

The done column is filled with completed tickets, showcasing all of the project's updates. Great work on completing your ticket and properly maintaining a professional team workflow using a sprint ticket and a sprint board!

Additional Sprint Tasks

Now that we have covered a simple version of a sprint ticket and a sprint board, I can offer you more details of my team’s process.

Additional Sprint Board Columns:

No Status: Tasks or tickets that haven’t been assigned a workflow stage yet.
Back Log: A list of tasks or ideas waiting to be worked on in future sprints.
Epics: Large, high-level tasks or projects broken down into smaller tickets.
Blocked: Tasks that cannot move forward due to an issue or dependency.

Leftover Tickets

What do we do with leftover tickets that weren’t completed during the sprint? They are usually moved back to the backlog or carried over to the next sprint for further work. Reviewing leftover tickets helps the team understand what caused delays and improves future planning, ensuring that important tasks aren’t forgotten.

Team Meetings

Stand-ups: Short daily meetings where team members share progress, plans, and blockers.
Weekly Meetings: Longer meetings held once a week to review progress, plan upcoming work, and discuss any issues.
One-on-one: Private meetings between two team members (often a manager and developer) to discuss individual goals, feedback, or concerns.

Future Sprint Planning

Sprint planning is the meeting where the team decides which tasks or tickets will be tackled in the upcoming sprint. During this session, team members review the backlog, estimate the effort required for each item, and agree on the sprint goals. The result is a clear plan that outlines what will be accomplished and who is responsible for each task, helping everyone stay focused and aligned throughout the sprint.

About Us

What is Gridiron Survivor?

What is the Elfgorithm App?

Gridiron Survivor Sponsors

A very special thanks to our sponsors!

GitKraken: A popular Git client that provides a graphical interface to manage Git repositories. It is known for its user-friendly design and features that simplify version control, making it easier for developers to collaborate and manage their code.
Frontend Mentor: An online platform that offers front-end coding challenges. It helps developers improve their skills by providing real-world projects to work on, along with a supportive community for feedback and learning.
Vercel: A cloud platform for static sites and serverless functions. It is designed to optimize the workflow of developers by providing tools for building, deploying, and scaling modern web applications with ease. Vercel is known for its seamless integration with frameworks like Next.js.

Be sure to listen to the HTML All The Things Podcast!

???? I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

A sprint is a short, focused period of work during which a development team completes specific tasks or goals. Sprints are an essential part of Agile development, a method of software creation that stresses flexibility, teamwork, and continuous improvement.

Sprint tasks are tracked using tickets that include detailed instructions. As work progresses, these tickets are moved across titled columns on a Sprint Board—To Do, In Progress, In Review, Testing, and Done, among others. Each ticket is assigned an estimated completion time by the assignee using a point system. Points represent time intervals that can differ between teams, such as point-1 for half a day, point-3 for one day, and point-5 for three days. Leftover tickets that weren’t completed during a sprint are typically moved back to the backlog or carried over to the next sprint for further work.

Regular team meetings keep everyone aligned and productive. Daily stand-ups help share progress and blockers, weekly meetings review progress and plan ahead, and one-on-ones focus on individual goals and feedback. Future sprint planning prepares the team for the next cycle by reviewing the backlog, estimating tasks, and setting clear goals. This ongoing process helps teams stay organized, adaptable, and successful.

Ready to implement Agile? Begin planning your next sprint and discover how this workflow can enhance your team’s productivity and project success!

Let’s connect! I’m active on LinkedIn and Twitter.

Sprint Workflow: A Beginner's Guide to Agile Development

Tue, 28 Oct 2025 00:09:50 +0000

In this article, we explore the sprint process in software development. You'll learn to manage tasks using a sprint board, track progress, and enhance team efficiency for successful project deliveries!

What Is a Sprint?

What is Agile Development

What is a Sprint Board & Ticket?

To Do
In Progress
In Review
Testing
Done

The index card lists tasks and moves through each column of the corkboard as the tasks are completed.

To Do	In Progress	In Review	Testing	Done
(TICKET)

To Do

Let’s write two tasks on the imagined index card:

Update the README file to include the new login feature
Add a URL link to the deployed project.

The provided index card (sprint ticket) will have an auto-generated number; let’s say it’s 12.

Now, I will assign YOU to complete ticket number 12. After reviewing the assigned tasks, you will let the team know how long it will take you to complete. This is done using a point system.

A point represents a time variable that can differ among teams. Our team’s point system is as follows:

point-0: within 2 hours
point-1: within 1/2 day
point-3: within 1 day
point-5: within 3 days
point-8: within 1 week

In Progress

Once you start working on your assigned ticket, you move it to the “In Progress“ column. When you complete it, you move it to the “In Review“ column and notify your team.

In Review

Testing

Done

Additional Sprint Tasks

Now that we have covered a simple version of a sprint ticket and a sprint board, I can offer you more details of my team’s process.

Additional Sprint Board Columns:

No Status: Tasks or tickets that haven’t been assigned a workflow stage yet.
Back Log: A list of tasks or ideas waiting to be worked on in future sprints.
Epics: Large, high-level tasks or projects broken down into smaller tickets.
Blocked: Tasks that cannot move forward due to an issue or dependency.

Leftover Tickets

Team Meetings

Stand-ups: Short daily meetings where team members share progress, plans, and blockers.
Weekly Meetings: Longer meetings held once a week to review progress, plan upcoming work, and discuss any issues.
One-on-one: Private meetings between two team members (often a manager and developer) to discuss individual goals, feedback, or concerns.

Future Sprint Planning

About Us

What is Gridiron Survivor?

What is the Elfgorithm App?

Gridiron Survivor Sponsors

A very special thanks to our sponsors!

GitKraken: A popular Git client that provides a graphical interface to manage Git repositories. It is known for its user-friendly design and features that simplify version control, making it easier for developers to collaborate and manage their code.
Frontend Mentor: An online platform that offers front-end coding challenges. It helps developers improve their skills by providing real-world projects to work on, along with a supportive community for feedback and learning.
Vercel: A cloud platform for static sites and serverless functions. It is designed to optimize the workflow of developers by providing tools for building, deploying, and scaling modern web applications with ease. Vercel is known for its seamless integration with frameworks like Next.js.

Be sure to listen to the HTML All The Things Podcast!

I also write articles for the HTML All The Things Podcast, which you can read on their website: https://www.htmlallthethings.com/.

Be sure to check out HTML All The Things on socials!

Affiliate & Discount Links!

To learn more about CodeMonkey, you can read my detailed review article!

Affiliate Links:

Advance your career with a 20% discount on Scrimba Pro using this affiliate link!

Important: This discount is for new accounts only. If a higher discount is currently available, it will be applied automatically.

How to Claim Your Discount:

Click the link to explore the new Scrimba 2.0.
Create a new account.
Upgrade to Pro; the 20% discount will automatically apply.

Disclosure: This article contains affiliate links. I will earn a commission from any purchases made through these links at no extra cost to you. Your support helps me continue creating valuable content. Thank you!

Conclusion

Ready to implement Agile? Begin planning your next sprint and discover how this workflow can enhance your team’s productivity and project success!

Let’s connect! I’m active on LinkedIn and Twitter.

Comparing Lean, Agile, and Continuous Delivery

Wed, 08 Oct 2025 14:46:30 +0000

With DevOps and Continuous Delivery gaining traction, are the principles behind Lean and Agile still relevant? How do they compare to the 5 Continuous Delivery principles, and what do any differences mean for software development teams?

The beginnings of lightweight software delivery

Throughout the 1990s, a revolution was brewing in the software development industry. The early phased models divided the delivery process into skill-based steps, with designs and documents used to run approval processes to control a project.

The process for delivering software was heavyweight and slow, with little indication that the overheads reduced the risks they tried to mitigate.

A collection of lightweight methods emerged, designed to generate fast feedback and iteratively adapt the plan based on new information. Rather than controls and approvals, developers used small batches to manage the risk and provide frequent opportunities to change direction.

The Agile Manifesto emerged from this adaptive and lightweight methods community in 2001, with Lean Software Development arriving a couple of years later.

Agile and Lean provided a values and principles based approach to software development. You could test whether an approach was Agile or Lean by testing it against a set of core statements defining each method’s philosophy.

Continuous Delivery emerged from the Lean and Agile communities, providing the most concrete practices and capabilities to achieve frequent and safe software delivery. Apart from Extreme Programming, most software development methods deal with requirements management and communication structures. Continuous Delivery takes on the rest of the value stream and provides a pathway to an efficient and reliable delivery pipeline.

InfoQ publishes an annual report on software development culture and methods. They style the report after Geoffrey Moore’s Crossing the Chasm concept. Moore famously visualizes a technology adoption lifecycle as a bell curve spread across 3 standard deviations.

The chart is divided into 5 groups with different attitudes to new technology:

Innovators (-3)
Early adopters (-2)
Early majority (-1)
Late majority (+1)
Laggards (+3)

The early majority and late majority represent two-thirds of the adoption lifecycle. Still, for new technology (or, in the case of InfoQ, a new idea) to move into the majority, it must cross the chasm from the early adopters to the mainstream majorities.

Source: InfoQ Software Development Culture and Methods 2022

While adaptive modes of software delivery are embedded in the late majority, the capabilities needed for continuous modes of delivery are still making their way across the chasm. Some practices (such as DevSecOps) have made the leap, while other key elements, like team topologies and empowered teams, remain at the early adopter stage.

So, with DevOps and Continuous Delivery gaining traction, it’s a great time to compare the 5 principles of Continuous Delivery with the 12 Agile principles and the 7 Lean principles.

Comparing Agile, Lean, and Continuous Delivery principles

Agile, Lean, and Continuous Delivery each provide a set of principles. This helps us compare their fundamental structures.

There are other techniques and capabilities in Lean and Continuous Delivery that don’t have comparable elements in Agile. The Agile Manifesto was intended to be a broad litmus test of the agility of other specific methods, such as Extreme Programming, Scrum, and Disciplined Agile, so it didn’t define further details.

Lean expands on its principles by describing techniques covering the whole software development process with advice on planning, design, testing, and maintenance.

Continuous Delivery uses the deployment pipeline to focus efforts on improving the flow of change, from the code commit to the software running in production. Specific technical capabilities are described in detail to enable the early and continuous delivery of valuable software.

The principles are the only directly comparable elements of these 3 approaches.

Continuous Delivery principles

There are 5 principles of Continuous Delivery:

Build quality in
Work in small batches
Computers perform repetitive tasks, and people solve problems
Relentlessly pursue continuous improvement
Everyone is responsible

The principles can be arranged into a reinforcing relationship, where the first 3 principles act as drivers of continuous improvement, for which everyone involved is responsible.

Agile principles comparison

In general, Continuous Delivery principles are consistent with The Agile Manifesto.

For example, working in small batches is widely understood to help achieve several of the Agile principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Simplicity — the art of maximizing the amount of work not done — is essential.

The phrasing of the principle “work in small batches” is concise and easy to follow in practice. This Continuous Delivery principle contributes to the attainment of half of the Agile principles.

There is also an amplification effect when you combine the 5 principles. To “deliver working software frequently”, you need to work in small batches, increase automation, and build quality in.

Two Agile principles are not covered by Continuous Delivery:

Business people and developers must work together daily throughout the project.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Continuous Delivery is centered on the delivery pipeline, which means the process of identification, inception, and initiation aren’t a direct concern of Continuous Delivery. Additionally, in the front matter of the Continuous Delivery book, the authors highlight that the book was created according to the ideas it contained. The contributors and editors worked using different tools and from separate locations. They used version control and automated builds to form a delivery pipeline for the book. They didn’t work together daily or convey information face-to-face.

As an industry, many organizations who hadn’t attempted to work remotely are now ready to experiment with distributed working. This will further challenge the need for real-time face-to-face coordination as asynchronous communication becomes more common and familiar.

Regarding word counts, Continuous Delivery principles are conveyed in 21 words, rather than 180 words for Agile principles. A combination of hindsight and incisive editing has given us a compass to check our direction, with the detail provided in the specific practices of Continuous Delivery.

"It’s easy to get bogged down in the details of implementing Continuous Delivery — CD tools, architecture, practices, politics — if you find yourself lost, try revisiting these principles and you may find it helps you re-focus on what’s important.” — Jez Humble

You don’t have to throw out The Agile Manifesto to move forwards; it’s part of the geography that Continuous Delivery and DevOps are building on. The industry will continue to discover new and better ways of developing software. It’s increasingly evident that technical practices and cultural capabilities are vital.

Lean principles comparison

The Lean principles are already brief and actionable. There’s complete alignment between Lean and Continuous Delivery, with no un-mapped areas.

With Agile, Continuous Delivery offered a concise alternative to 10 Agile principles. In the case of Lean, Continuous Delivery aligns entirely with the principles. Each approach provides a different perspective that applies to various organization segments.

In an organization that has fully adopted both Lean and Continuous Delivery, the respective principles are helpful to different groups. Lean principles and techniques are leadership tools, while Continuous Delivery provides an approach specific to the individual contributors’ delivery efforts.

For example, automation is a practical attack vector for eliminating waste, delivering quickly, and building integrity into the system with Continuous Delivery.

Conclusion

Continuous Delivery provides a concise set of principles that align with 10 of the 12 Agile principles and complement Lean, providing a different perspective on achieving similar goals.

All 3 sets of principles are consistent with modern management philosophy and provide different ways to review and re-focus your software delivery efforts.

You can use the Continuous Delivery principles to guide your software delivery efforts and refer back to Agile and Lean principles to find further inspiration for your improvement efforts.

Scrum Must Die ☠️

Tue, 19 Aug 2025 14:32:03 +0000

Scrum was born as the savior of development teams.
Now, in too many companies, it’s turned into a corporate religion with more sermons than miracles.
And like any bureaucratic religion... it either reforms, or it dies.

Scrum: from agile revolution to organizational theater

Years ago, when someone said "we're agile," people smiled.
Today, it means: "brace yourself for more meetings, more metrics, and more PowerPoints."

Once, companies hired Scrum Masters and Agile Coaches like rare Pokémon.
Now? They're laying them off, merging their roles, or keeping them as ceremony police.

The slow death of technical excellence ⚰️

Scrum doesn't ship technical practices out of the box.
Without a strong engineering commitment — tests, CI/CD, TDD, living architecture — the framework becomes a conveyor belt of broken features.

The result:

Code that ages worse than a banana forgotten in a drawer.
Deadlines that dictate more than quality.
Developers stuck in chronic burnout.

The mutant Scrum Master

In too many organizations, the Scrum Master is gone.
Instead, we have the Scrum-PM-Dev-Tester-CoffeeMaker: a hybrid creature that doesn't lead or serve, just survives.

A role meant to protect agility now spends the day filling spreadsheets and chasing tickets instead of empowering teams.

Management overload and the cost of ignorance

There's a growing management overload in many "agile" organizations: too many decision-makers with too little technical background.

This creates a dangerous loop:

Decisions are made without understanding the engineering impact.
Expensive mistakes are repeated in the name of "delivery".
Teams feel they're being managed, not led.

When non-technical managers dictate technical priorities, the result is often waste, rework, and long-term pain disguised as "progress".

The Agile Industrial Complex

Agility has been packaged into certifications, workshops, and consulting packages that promise transformation but deliver empty mechanics.

Scrum becomes a theater where everything is done "by the book" but without soul, values, or real continuous improvement.

Reform it or throw it overboard?

If you still want to rescue Scrum, here's the recipe:

How Scrum could improve:

Less ceremony, more value: if the daily stand-up lasts 20 minutes, something's broken.
Integrate technical practices: TDD, CI/CD, Pair Programming… without this, forget about quality.
Clear roles: a Scrum Master is not your Project Manager, boss, or on-call developer.
Real autonomy: the team decides, not the hierarchy.
Technical literacy in management: decision-makers must understand the cost and complexity of engineering work.

Alternatives that might shine brighter:

Kanban: flows like water, no forced iterations.
Extreme Programming (XP): hardcore engineering, quality above all.
Lean: less waste, more focus on what matters.
Mix & Match: take what works, drop what doesn't — like a good buffet.

Conclusion: Scrum isn't the enemy... but your implementation might be

Scrum doesn't have to die, but the zombie, bureaucratic, tech-agnostic Scrum we see in too many companies... that one should be buried.
Preferably with one last retrospective... and no sticky notes.

A guide to deciding what ,why and when To Pivot or to Persevere?

Sat, 26 Jul 2025 07:58:17 +0000

#The Founder's Dilemma: To Pivot or to Persevere?

When you're building something new, whether it's a startup or a project, you'll face a big question over and over: should you stick with your original plan, or is it time for a change? This is the classic choice between pivoting and persevering, a key idea in modern product development that comes from popular methods like the Lean Startup and Agile.

What Does it Mean to Pivot or Persevere?

Persevering is all about sticking to your guns. It means you believe in your current plan and are committed to seeing it through, even when things get tough. You have faith that your idea is the right one, and you're willing to put in the time and effort to make it work.

A pivot, on the other hand, is a major change in direction. It's not just a small adjustment; it's a deliberate decision to try a new approach because the old one isn't working. You're essentially admitting that your initial idea needs a rethink to find a path to success.

The main difference is the size of the change. Persevering is about improving your current path, while pivoting is about finding a new one.

Making the Call: Why, When, and What to Do?

Deciding whether to pivot or persevere is one of the most important decisions a team can make. The wrong choice can cost you time, money, and even the entire project.

Why is this decision so important?

This choice affects everything. It shapes how you use your resources, keeps your team focused, and determines if your product will ever be a hit with customers. A smart pivot can rescue a failing company, and determined perseverance can turn a good idea into a great one.

When should you consider a pivot?

Knowing when to pivot is tricky, but here are some signs to look for:

Stagnant Metrics: If your key performance indicators (KPIs) are flat or declining despite your best efforts, it might be time to reconsider your strategy.
Negative Customer Feedback: If your target audience is consistently telling you that your product doesn't solve their problem or that they wouldn't pay for it, you need to listen.
The "Get Out of the Building" Test: As advocated by the Lean Startup methodology, if your interactions with real customers reveal that your initial assumptions were wrong, a pivot is likely necessary.
A better opportunity appears: Sometimes, you'll discover a bigger and better idea while working on your original one. It might be worth pivoting to chase it.

How to decide which path to take?

Data-Driven Decisions: Rely on metrics and qualitative feedback, not just gut feelings. Use agile feedback loops to gather data continuously.
Set "Pivot or Persevere" Meetings: Hold regular, dedicated meetings to evaluate progress against goals and openly discuss the possibility of a pivot. This makes the decision a part of the process, rather than a reaction to a crisis.
Know what you're testing: Be clear about the assumptions you're making. This will help you know if your ideas are being proven right or wrong.

Real-World Scenarios

The Pivot Hall of Fame

Slack: Originally a gaming company called Tiny Speck working on a game called Glitch, the team built an internal communication tool to collaborate. When the game failed to gain traction, they realized their communication tool was the more valuable product. They pivoted to focus on it, and Slack was born.
YouTube: Started as a video dating site called "Tune In Hook Up." When that idea failed to take off, the founders noticed that users were uploading all kinds of videos, not just dating profiles. They pivoted to a general video-sharing platform, and the rest is history.
Instagram: Initially a location-based social network called Burbn, it was cluttered with features. The founders noticed that the photo-sharing feature was the most popular. They stripped away everything else and focused solely on photos, filters, and sharing. This pivot created the Instagram we know today.

The Power of Perseverance

Amazon: Jeff Bezos's vision for Amazon was always to be "the everything store." In the early days, many doubted that an online bookstore could succeed, let alone expand into countless other categories. Amazon persevered through the dot-com bust and years of unprofitability, staying true to its long-term vision.
Netflix: From its beginnings as a DVD-by-mail service, Netflix faced intense competition from Blockbuster. They persevered, believing in the convenience of their model. Later, they made the monumental decision to cannibalize their own successful business by moving into streaming, a move that required immense perseverance through technical challenges and licensing negotiations.

Conclusion

Building something new is never a straight line. It's about learning, experimenting, and making smart changes along the way. Knowing when to stick with your plan and when to make a change is what sets successful projects apart. By using data and being open to change, you can make the right call and give your ideas the best chance to succeed

Understanding Tech Debt

Sun, 13 Jul 2025 07:21:40 +0000

Understanding Tech Debt

Understanding Tech Debt

What is Tech Debt in Software Development?

Think of technical debt (or tech debt) as taking a shortcut when writing code. You choose a quick and easy solution for now, knowing that you'll have to come back and fix it properly later. It's like borrowing money. You get something now, but you have to pay it back later, and often with "interest." This "interest" means that making changes to your software in the future will be slower and more difficult because of the shortcut you took.

What is Tech Debt in Agile and Scrum?

In agile development, where the goal is to release software in short cycles (sprints), teams can easily create tech debt. The pressure to finish work within a sprint might lead them to cut corners.

Here are some things to watch out for in agile:

Meeting Deadlines: Rushing to meet a sprint deadline can lead to messy code.
Changing Plans: When project needs change, the old code might not be a good fit anymore.
What "Done" Means: A good team agrees on what it means for work to be truly "done." This should include writing clean code.
Making it a Task: The best way to handle tech debt is to add it as a task in the project plan. This way, it doesn't get forgotten.

Common Examples of Tech Debt

Tech debt can show up in many ways. Here are a few common examples:

Code-Level Debt

No Instructions: Code without comments or documentation is hard for others (or your future self) to understand.
Not Enough Testing: Without good tests, fixing one thing can accidentally break something else.
Copy-Pasting Code: Writing the same code in multiple places instead of making one version that can be reused.
Mysterious Numbers: Using numbers in code without explaining what they are for.

Database Debt

Poor Normalization: Storing the same piece of information in multiple places. For example, having a customer's address stored with every order they make instead of in a separate customer table. This makes updates difficult and can lead to inconsistent data.
Inconsistent Naming: Using different names for the same kind of data in different tables (e.g., CustomerID in one table and Cust_ID in another). This makes writing queries confusing and error-prone.
Missing Indexes: A database index helps find data quickly. Without a proper index, the database has to search through every row to find what it's looking for, which can be very slow, especially with large amounts of data.
Ignoring Data Types: Storing data in a generic type (like a text field) when a more specific type (like a date or number) would be better. This can lead to bad data and makes it harder to work with.

Architecture and Infrastructure Debt

Tightly Coupled Components: Creating parts of the system that are so dependent on each other that changing one part requires changing many others.
Outdated Dependencies: Using old libraries or frameworks with known security holes or performance issues.
Lack of Automation: Manually deploying code or running tests when these processes could be automated. This is slower and increases the chance of human error.

Conclusion

Tech debt happens in almost every software project. Sometimes, taking shortcuts is necessary to get things done quickly. But it's important to keep track of these shortcuts and plan to fix them. If you don't, your software will become hard to work with over time. The best approach is to deal with tech debt regularly to keep your code clean and easy to maintain.

Two Ways to Reduce Bottlenecks with the Theory of Constraints

Mon, 30 Jun 2025 12:26:04 +0000

Working out how to apply Theory of Constraints in real-world situations can be hard, but there are two simple ways to kickstart it.

A chain is only as strong as its weakest link. That’s the idea behind the Theory of Constraints. Just a few weak links will limit any system, but you can improve the whole system’s performance by focusing on improving those links.

Whether your system is a software delivery process, a large production line or your household chores, the only way to improve the whole system is to work at the bottlenecks.

Theory Is Great, in Theory

There are two ways to learn about the Theory of Constraints. You can read Eliyahu Goldratt’s business novel, The Goal, or read the accompanying handbook, Theory of Constraints.

Either option explains the set of focusing steps you use to apply the theory.

Identify the system’s constraint.
Decide how to exploit the constraint.
Subordinate everything else to this decision.
Elevate the constraint.
If the constraint resolves, go back to step one.

The theory is wide-reaching. It can be applied to any system. For example, a production line in a factory, managing software delivery or a group of Scouts trying to hike to their destination with their equipment. Because of this, the language is likely to be a little abstract for your real-world situation.

Specifically, the terms exploit, subordinate and elevate might be unclear.

Let’s simplify the language a little, then look at two practical ways to apply the Theory of Constraints to your work.

Exploit, Subordinate and Elevate

A “constraint” in the Theory of Constraints is essentially a bottleneck. You are trying to flow work to completion to get some value, and many steps are involved, possibly many people. If you look closely at this flow of work, you’ll find there is one stage where things get stuck.

You might be making computers and have a pile of almost finished products stacked, waiting for someone to install a graphics card. Well, the graphics card stage is your bottleneck or constraint.

You can spot this problem thanks to the pile of computers sitting in front of the graphics card workstation, but you’ll also notice workstations after the bottleneck are starved of work while those ahead of it are producing more laptops that only add to the size of the queue.

If your work is less physically visible, having a visual system like a Kanban board can show you the problem. Seeing work items stuck in a queue in front of a specific task shows you ther’s a bottleneck.

When you can see this bottleneck, you’re ready to apply the three mystical terms.

You can exploit the constraint by improving it with existing people and resources. If you can transfer someone to work at the constraint, your overall production (finished laptops, software features or clean clothes) will increase.

You then subordinate everything else to the pace of your constraint. That means setting the speed of the upstream process to match the speed of the bottleneck. If you can fit 10 graphics cards into laptops in a day, you can assemble only 10 laptops a day. Everything from start to finish runs at the pace of the stage with the bottleneck.

Once the system is running at a matched speed, you look at ways to elevate the constraint. That means finding ways to increase the throughput from 10 graphics cards daily to something more than 10. Assuming you’re not using existing people and resources to elevate the constraint, you’ll need to look at the costs and benefits of increasing throughput. If you doubled the size of the team or introduced tools to support the process to increase throughput to 20 graphics cards a day, how much would you invest to get those extra sales?

You continue to apply this three-stage process until the constraint moves. For example, you are producing 20 graphics a day while selling only 18 laptops a day. Now you apply the focusing steps to the sales stage instead.

This theory can be applied to physical or knowledge work. Work is like water flowing down a canal with many locks. You can’t allow the water from higher stretches to flood the lower ones or allow a section of the canal to run dry.

Let’s look at two practical ways to apply these focusing steps in real life.

Start on the Right

In software development, work is usually visualized on a task board that follows work as it flows from left to right. The columns on the board represent queues and work stages, such as “waiting for testing” and “in test.”

To apply the Theory of Constraints, first ensure the task board accurately represents every hand-off and queue in your process. Once you have represented the real flow of work, the board will quickly show you where bottlenecks are.

You can apply the focusing steps to the bottleneck, but there’s a simpler option for cross-functional teams. Always work on the right-most work item before anything else. If a feature is ready to deploy to production, deploy that before testing the feature to the left.

By always progressing the work closest to completion, you get the exploit and subordinate focusing steps with no effort. Your cross-functional team is self-leveling, even for dynamic bottlenecks. The speed of the system is automatic, and the team will apply their time flexibly to the tasks that require their attention.

When using this approach, you just need to keep inertia out of your improvement process. You won’t have a stack of work telling you what needs to be improved, so you’ll need to pay attention to which tasks must be improved — or elevated, in Theory of Constraints terminology.

Sometimes, the simplicity of this approach is what makes it so powerful.

Schedule to the Bottleneck

If you don’t have a cross-functional team, you can schedule to the bottleneck. For example, if you have a separate testing team, you should produce features only at the speed they can be tested without increasing the queue size.

This is where adding work in process (WIP) limits to your task board can help. The most important WIP limit is the one for the queue in front of the bottleneck, but you may need to add limits to other columns to the left of the constraint. You don’t need limits after the bottleneck; if you find yourself adding WIP limits on the right, it means your constraint has moved.

When you schedule to the bottleneck, ideally you want to provide work to the constraint just as they need the next task. However, most teams use a buffer to make sure the bottleneck is never idle.

Scheduling to the bottleneck takes more effort than starting on the right. However, its one advantage is highlighting the constraint very clearly. Nobody on the team has any doubts where improvement efforts should be focused.

The Powerful “Aha” Moment

The reason the Theory of Constraints has such an impact is that it highlights how all the work you do above what your bottleneck can handle is wasted. In the laptop example, no amount of assembled laptops you produce makes a difference to how many you sell if you can’t complete them with a graphics card.

The answer can be as simple as moving someone from assembly to graphics installation, or you may need better tools to support this stage in the process. The Theory of Constraints sets you on the right path and provides concrete motivation for improving the right thing.

Why Maturity Models Are Fundamentally Broken

Mon, 09 Jun 2025 07:57:57 +0000

Maturity models make complex things appear simple, but we need to acknowledge the circumstances behind them being imposed on so many organizations.

There’s a certain appeal to maturity models. They take a lot of complexity and arrange it neatly into simple steps called maturity levels. Just tick off everything in the first level to move on to the next.

Maturity models owe their traction to the way they make complex things appear simple. In particular, they can take a subject and present it to someone with no expertise in the subject in a way that they can understand.

The simplicity of the maturity model is also its greatest weakness. Still, if we’re to move past them, we need to acknowledge the circumstances that result in them being imposed on teams in so many organizations.

Let’s quickly summarize why maturity models are fundamentally flawed, and then explore what you should do instead.

‘Best’ Is Always Contextual

I worked for an organization in the health-care industry that needed to create a new software product. Thanks to an overzealous sales team, a suitable crisis had been created that meant the organization was willing to give the team whatever it needed to deliver the first version of the product.

We formed a small team that included everyone needed to deliver the software, including a clinically trained nurse. We experimented with the process to enable a highly collaborative approach with single-piece flow and fast feedback loops. We used a retrospective process after each feature to fine-tune the process.

After several iterations, we could deliver a feature every three hours. Over the course of six months, we delivered many working versions of the software with zero regression defects.

Having the autonomy to devise our own process allowed the team of clinical and technical people to create a process that perfectly fits the complex and challenging environment. It was the best process we could have applied to the problem at hand.

When the managers in the organization saw how well this process worked, they couldn’t wait to roll it out to all the other software teams. There are several problems with this kind of standardization effort.

The process and capabilities don’t bring the magic. It was a mixture of these practices and the close collaboration between the clinical and technical team members. We also had total commitment to the process because we created and adjusted it. The drivers for each change and the evidence of what worked and what didn’t meant we understood why we were working this way.

The crucial factor that made this team so successful was autonomy.

And this is the heart of the problem. The one thing that is so important in creating a successful team and a working process is the very thing a maturity model removes.

Maturity Models Only Work in the Lab

Maturity models are not unreasonable. As statistician George Box once said, all models are wrong, but some are useful. They are based on specific starting and target conditions. Each model is created in response to an undesirable situation and a vision for a desired future state. They capture the steps to move between two defined points.

If you have the same undesirable starting point, a maturity model will likely bring you the described outcomes. For example, the Software Capability Maturity Model (CMM) gained traction in the movement to bring professionalism to software development because so many organizations shared the same untenable starting position.

Even with high traction, results are highly variable because organizations adopting maturity models have different contexts to those the model’s authors had experienced. Designing a single model that produces the same results in the face of different products, industries, people and organizational cultures is impossible.

Many attempts to introduce maturity models fail in the change management process. Some managers drop copies of “Who Moved My Cheese” on every desk, letting employees know they are the problem. Others attempt to run an internal marketing campaign, which results in eye rolls and collective lethargy. No slogan written on a pen ever saved a company from self-destruction.

When attention isn’t paid to the process of change, it fails. Because maturity models have “we know better than you” baked in, they are a disaster for transformational efforts.

This brings us back to the key ingredient of a working software delivery process: autonomy.

Instead of defining precisely how professional software developers work, they should be allowed to solve this problem themselves. Where there are constraints, developers will find creative ways to meet the needs of the business. If you are in a safety-critical or regulated industry, they will achieve the necessary conditions.

The best process for the team and the organization will be the one they create. It will remain the best way to solve the problem if they regularly adapt the process to improve it.

To counter George Box’s statement about models being wrong, we can turn to statisticians Peter McCullagh and John Nelder, who said:

“All models are wrong; some, though, are better than others, and we can search for the better ones. At the same time, we must recognize that eternal truth is not within our grasp.”

A Way Forward

If you measure the impact of each practice listed in a maturity model, you’d know whether they improved outcomes, made no difference to outcomes or made things worse. You’d end up not adopting all the practices, just the effective ones. This is the basis of a capability model.

Capability models encourage continuous improvement. You can tailor the capability model to your context and adjust as circumstances change. Instead of applying a required set of practices, you look for capabilities that will improve outcomes.

For software delivery, the best example of this is the DORA capability model. There are no maturity levels or sequence of steps. You don’t even have to adopt every item listed in the model.

Instead, you reflect on your future desired state and use the model as a source of ideas. By tracking outcomes, you can avoid making things worse and spot potential problems. Throughput and stability metrics are common measurements, as they balance competing demands well.

You may introduce additional metrics to track specific improvements. If you focus on making the deployment pipeline faster, you might track the time it takes to build or test the software. Any measurements you collect must be retired when they are no longer needed or converted into fitness functions that will alert you if a problem resurfaces.

A capability model provides hints on practices that predict certain outcomes. You are encouraged to confirm that this relationship applies in your case, rather than applying capabilities on faith alone.

You must also develop each skill rather than meeting a minimal evidentiary bar. Introducing a practice like test automation will likely slow things down for a while as the skills are developed. Once sufficient mastery is achieved, the difference becomes visible.

Stay Away from DevOps Maturity Models

Adopting a technique or practice requires some investment. Maturity models disregard the cost/benefit trade-off. While some models are based on academically rigorous research, it’s still essential to orient improvement efforts to the context of your team and organization.

If someone offers you a DevOps maturity model based on the DORA research, remind them that many members of the DORA team, including its co-founder Nicole Forsgren, have said it’s a bad idea.

Coder Legion - Recent posts tagged agile

How to bulk edit Azure DevOps work items without Excel (works on Mac)

cover_image: https://jr-devtools.com/bulk-editor/screenshot-grid.png

1. Bulk edit in the query results (built in)

2. CSV export and import (built in)

3. A spreadsheet grid in the browser

Which one should I use?

Related guides

The thinking behind Millrace

Slow and steady, not slow and heavy

Finish the good stuff and let mediocre ideas fall away

A certain level of polish

Calm, slow, smooth, fast

Fin

Am I Deployable?

Why Agile Does NOT Mean "We'll Figure It Out Later”

If Agile Welcomes Change, Why Plan At All?

Where The "Agile Means No Planning" Myth Comes From

What Happens When Teams Truly Stop Planning

Agile Never Removed Planning — It Removed Excessive Planning

The Different Kinds of Planning Happening Inside Agile Teams

How Agile Plans Differ From Traditional Planning

So What Happens When The Plan Changes?

Millrace: Git-backed Kanban

Slow and steady, not slow and heavy

Finish the good stuff and let mediocre ideas fall away

A certain level of polish

Calm, slow, smooth, fast

Fin

Shaped Kanban: Complete Features, Not Sprints

The Timebox Problem

The Calendar Fills Itself

Different Teams, Forced Cadence

Ceremony Fuels Continuation Bias

Shaped Kanban: Discipline Without Shared Timeboxes

How Shaped Kanban Works

1. Shaping

2. Betting

3. Circuit Breakers

4. Kanban Flow

5. Technical Debt Without a Cooldown

Multi-Team Coordination Through Explicit Dependencies

How This Approach Can Fail

When to Consider This Approach

How Sprint Planning Actually Works

Why Modern Software Development Needs Better Planning

How Smaller Development Cycles Changed Modern Teams

So What is Sprint Planning Actually?

Where Does All The Work Come From?

How Teams Decide What Fits Into a Sprint

Why Sprint Planning Often Fails in Beginner Teams

Sprint Goals — The Part Most Teams Ignore

Sprint Planning is Not About Predicting Everything Perfectly

Agile Explained Simply for Beginners

What is Agile?

Why Agile Exists

Agile Mindset

Why is Agile Called an Iterative Approach?

Why Customer Feedback Matters in Agile

Flexibility and Adaptability in Agile

Important Agile Concepts Everyone Should Know

1. User Stories

2. Story Points

3. Product Backlog

4. Sprint Backlog

5. Sprint

6. Scrum or Daily Standups

7. Retrospectives

8. Velocity

9. MVP

AI Makes Us Faster. Agile Keeps Us Pointed in the Right Direction.

Speed does not replace direction

Agile was never just about moving faster

For solo developers and founders

For teams using AI

Agile as a direction validation loop

Why Your Story Points Feel Arbitrary (And How to Fix It)

The four dimensions

Rating guide

How I map ratings to points