GitHub Projects in 2026, Part 1: It Can Do Anything. That's the Problem.

This is Part 1 of 4 in the GitHub Projects in 2026 series.
Next: Part 2: Why Projects and Issues Feel Weird (and Why It Makes Sense) →

Shameless plug: Already running your team in GitHub Projects? Honest Cheetah adds test management and "when will it be done?" forecasting right inside GitHub, using the data you already have. It measures the system, not the people.

▶ Watch this video on YouTube (opens in a new tab)

Back in 2025, I did a fifteen-video series on running Scrum with GitHub Projects. A lot has changed in a year. GitHub shipped a pile of stuff (here's the scorecard), the industry's opinion of Scrum has gotten even grumpier, and AI coding agents went from "huh, neat" to "wait, it's assigned to the robot now?" So I'm doing a refresh. This is Part 1.

And Part 1 is the 40,000-foot view. No demos yet. Before I show you a single field or view, I want to talk about why GitHub Projects works the way it does, because if you don't have a philosophy going in, you're going to end up with what I call a very flexible mess.

TL;DR

• GitHub Projects is a lens over your issues. It'll run any process you want. It ships with no process at all. That's on purpose.
• Flexibility without a philosophy gets you fields nobody fills in, ten views nobody uses, and statuses that mean different things to different people.
• The world is sick of agile and Scrum. Some of that is fair. But Scrum didn't slow you down. It showed you how slow you already were.
• Steal the good parts. I call it agile-ish: know what done means, finish before you start, measure outcomes, treat discomfort as a signal, and prioritize ruthlessly.
• Every GitHub Projects setup should answer the All-New Three Questions: What are we going to work on? What are we working on right now? Are we on track?

Flexible Project Management

Here's the thing about GitHub Projects: whatever your process is, they want to support it. Which is hard for them, because that means solving for the set of all possible development processes. Philosophically, they're not trying to force you to work their way. They're trying to be flexible and meet you where you are.

That's a nice sentiment. It's also a little uncomfortable, because non-judgmental flexibility means the tool isn't going to stop you from making a mess.

My goal for this series is to help you understand why GitHub Projects works the way it works, and then, of course, to actually be successful at developing and delivering your software with it.

What GitHub Projects Is Trying to Be

Let's look at what GitHub is going for here, because it's pretty deliberate.

• A lens over your issues. Think of a project as a flexible spreadsheet plus a kanban board plus a roadmap, all wired into your repos.
• Any process. Scrum, Kanban, a roadmap for the timeline people, or something you invented last Tuesday. It doesn't care.
• You design it. You add whatever fields make sense for your team, you make whatever views and layouts you want, and you set up your own automations.
• The sweet spot. The old GitHub Issues was too simple for real project management. GitHub Projects is aiming for enough structure to be useful, without forcing you into somebody else's framework.

What It's Not Trying to Be

Just as important is what GitHub Projects isn't trying to be.

• No process. It doesn't ship one. That's a big difference from Azure DevOps, where you pick a process template and that template comes with opinions about pretty much everything.
• No timesheets. You're managing work items here, not hours.
• No capacity planning. There's no view that tells you how many hours somebody has left this week, and I don't think there ever will be.
• Your call. That's not GitHub forgetting stuff. They left those decisions to you, on purpose.

Flexibility Without a Philosophy

Now I know what you're thinking. "Flexibility is good, Ben." And sure, it is. But here's what flexibility without a philosophy actually looks like on a real board.

Fields nobody fills in. Somebody added Priority. Somebody else added Severity. Somebody else added Importance. Half the items have none of them.

Ten saved views nobody uses. Each one made perfect sense to the person who made it, on the day they made it.

Statuses that mean different things to different people. Is "In Review" code review, or is it waiting on the product owner? Depends who you ask, right?

Sound familiar?

So you need a core philosophy before you configure anything, because the tool won't decide for you.

Going Off-Road

Ok. I have a point to make about project management, but it's going to require a bit of an off-road excursion. Bear with me. If you start getting bored, skip ahead to the All-New Three Questions.

Let's Face It: The World Got Sick of Agile and Scrum

A lot of people in our industry have decided that agile and Scrum just aren't good and they never want to hear either word again. I understand why. I don't 100% agree. But I'd still like you to steal all the good ideas.

Here's what I hear kind of a lot:

• "Scrum slowed us down." I've heard this from CTOs, VPs of engineering, project managers, and individual developers.
• "Too many meetings." Standup, planning, review, retro, refinement. "I can't get any real work done."
• "We never finished on time anyway." Commit to ten things, finish four, drag the rest into the next sprint.
• "Story points are planning theater." Who cares if it's a five or an eight? We all know the estimates are wrong.
• "Process for its own sake." Underneath all of it, the feeling that it's a whole lot of process just to have process.

Yeah. I get it. I hear you. I can see where every one of these comes from.

Before Scrum: Waterfall

Think about what came before Scrum. For those of you lucky enough to have started your career in the post-waterfall world, here's the super fast overview.

You had project plans in Microsoft Project, with Gantt charts galore. Every task, every dependency, every date, all planned out up front. You had giant requirements documents, hundreds of pages, and everybody had to sign off on them before anybody wrote a line of code. Then you went phase by phase: requirements, then design, then development, then testing, then user acceptance, and finally deployment.

And the result of all that planning? Tons and tons of failed software projects.

What If People Talked to Each Other?

Waterfall really didn't work, and the agile world replaced it with the mind-blowingly outlandish idea that perhaps, just perhaps, people should talk to one another.

Because software development is hard. It felt like you should be able to get perfect requirements and perfect plans and iron out all the uncertainty up front. Experience showed it just didn't work. You'd write hundreds of pages of requirements that were wrong, and then you'd deliver the wrong thing, wrongly.

The Real Problem: The Feedback Loop

If I really try to boil down why waterfall didn't work, it all comes down to how fast your feedback loop is. Your ability to get feedback is probably the second most important thing for success. (The number one thing is having a shared understanding of what "done" means. But anyway. Feedback.)

With waterfall, feedback and introspection happened on the timeline of the whole project. By the time you found out you were late, you were eighteen months into a project that was supposed to be done six months ago.

Then Scrum came along with the sprint. Back in the early days, thirty-day sprints were really common. The idea that you'd ship done features in thirty days or less? Revolutionary.

Think about what that thirty-day loop actually bought you:

• Having trouble delivering? You find out in thirty days or less.
• It doesn't work the way you thought it would? Thirty days or less.
• The customer decides those thirty features you'd been planning aren't necessary anymore? You find that out fast, too.

Inspect and adapt, on a maximum duration of thirty days. For the time, that was a very big deal.

And today, a lot of teams can get feedback continuously, in days. Hang on to that. I'll come back to it.

25 Years Later

Here's the thing, though. All of that happened right around the year 2000. And over the last twenty-five years or so, a whole lot changed.

The internet is fully baked now. It was pretty darned new back in 2000, and it turned out the web wasn't a fad. Cloud computing is a thing. JavaScript isn't evil anymore (mostly). We all have phones in our pockets that do real, useful, non-telephone stuff. Remote work is a thing, and so is Git, with easy branching and merging that just works. And now AI coding agents are a thing. There are probably another half dozen things I didn't even think to mention.

Agile and Scrum were a solution for software development circa 2001. The software world just isn't the same anymore.

Oops. Sorry.

There's one more piece of this, and honestly, it's kind of my fault.

A whole bunch of people like me sold a whole lot of agile transformation engagements. Those ran headfirst into corporate cultures and icky human communication habits, and a lot of those transformations never quite paid off. Oops. Sorry about that.

Because cultural change takes a long time. And here's the thing: software culture really did change. It just changed on its own schedule, thank you very much.

Along the way, a lot of people got burned by an army of not-great Scrum trainers who emphasized doing the meetings over the actual goal, which was delivering software.

Scrum Didn't Slow You Down.

So here's my theory about why the whole agile movement fell out of favor.

Before Scrum, you'd work for six months, miss a deadline, and blame the requirements or the database team. Then Scrum put a two-week mirror in front of your process and said, "Look. This is what you actually got done."

Scrum didn't slow you down. It showed you how slow you already were. And for most teams, that was deeply, deeply uncomfortable.

OK, Some of Those Meetings Really Were Terrible

That's a deliberately provocative way to put it, and some of those meetings really were terrible. So let's be fair about it.

• Story points. Your team spends an hour arguing about whether something's a three or a five, and then it takes three weeks anyway.
• Rigid sprint boundaries. You commit to ten items, finish seven, and now your burndown looks terrible and everybody feels bad. The boundary created that failure, not the team.
• Mandatory ceremonies. Some of them are valuable some of the time. But when they're rituals, people zone out and go through the motions.

Both things are true. The mirror was real, and a lot of the ceremony around it really was a waste of time.

The Era of Nothing in Particular

So where are we now, in 2026? I think we're in the era of nothing in particular, plus agentic AI.

The industry basically treats Scrum like a four-letter word. At the same time, we're all trying to figure out what to do about AI coders. Because writing code isn't the slow part anymore. AI can write code about a hundred times faster than I ever could. Code isn't the constraint.

Vibe-coding is real. So is vibe-confidence. But vibe-maintenance isn't real, and vibe-planning definitely isn't real.

So we hate Scrum, we hate agile, and we're going through a total dinosaurs-meet-the-comet moment.

Forget the Goals of Scrum, Repeat Its Mistakes

Here's my prediction. My two cents.

Companies who forget the goals of Scrum are doomed to repeat the problems Scrum was trying to fix.

The meetings were never the point. The point was a short feedback loop, an honest look at what's actually done, and the freedom to change your mind. You still need all of that. AI or no AI.

Agile-ish: Yoink the Good Parts

So let's just yoink all the good parts out of Scrum and use them for modern software development. I call this agile-ish.

1. Know what done means. A shared, honest definition that everybody on the team, and everybody who depends on the team, can see. (If you don't have one, steal my sample Definition of Done.)
2. Finish before you start. Stop starting new things. Start finishing the things that are already in progress.
3. Outcomes over outputs. Counting finished work matters, but it's not the whole story. Flow tells you whether you're predictable. Outcomes tell you whether it mattered.
4. Discomfort is a signal. When your process makes something uncomfortable visible, that's the diagnostic working. Be curious about it instead of running from it.
5. Prioritize. Multitasking destroys you at the individual level, the team level, and the org level.

Ok. Back on the road. Let's get back to GitHub Projects.

Why the All-New Three Questions?

If you've done Scrum, you probably remember the old three questions from the daily standup. What did I do yesterday? What am I doing today? Is anything in my way?

The 2020 Scrum Guide actually dropped those. And good riddance, because those questions were all about each person reporting their status.

So I've got three new ones. They're about the team's system, not the people.

The All-New Three Questions

Here's the core that you configure everything else around. Your setup in GitHub Projects needs to answer these three questions.

1. What are we going to work on? You need one prioritized list of stuff. Call it a backlog, call it a to-do list, I don't care, as long as it's one place and it's in order.
2. What are we working on right now? What's in progress, who's on it, and what's blocked? If somebody asks for status, you shouldn't need a meeting to answer that.
3. Are we on track? Are we actually finishing stuff, or are we just busy? There's a big difference between activity and progress.

A good setup answers all three without a meeting. Every field, every view, every automation in your project should help answer one of these three questions. If it doesn't, you probably don't need it.

Because, one more time: the tool won't decide for you.

Shameless Plug

I built a product for GitHub called Honest Cheetah. It's got the tools to answer the important questions like "when will it be done?", plus AI-assisted project management and project coaching, QA testing tools, and the ability to import your work items and test cases from Azure DevOps. Please consider trying it out.

Next Up: Part 2

This post covered a whole lot of project management philosophy, and hopefully you didn't completely hate it.

In Part 2, we'll look at why GitHub Projects and GitHub Issues work the way they do, and why the split between them sometimes feels a little weird. We'll also look at where Projects fits with the rest of GitHub: how you connect project management to development, delivery, and DevOps.

The hands-on demos start in Part 3.

-Ben

-- Looking for help adopting GitHub Projects for your team or your company? Need an assist getting going with GitHub Actions for automated builds and releases? Want to move your stuff over to GitHub from another service? We can help. Drop us a line at info@benday.com.

GitHub Projects in 2026: The Full Series

• Part 1: It Can Do Anything. That's the Problem. (you are here)
• Part 2: Why Projects and Issues Feel Weird (and Why It Makes Sense)
• Part 3: Your First Project, From Draft Issues to Real Issues
• Part 4: Taming a Messy Backlog with Issue Types

Related:

• What's New in GitHub Projects & Issues (2026 Q4): what GitHub has shipped since the original series
• The 2025 Scrum with GitHub Projects series
• Agile-ish: Lightweight Project Management with GitHub Projects (VSLive Vegas 2026)
• The GitHub Projects in 2026 playlist on YouTube