By Emanuel Torres, MBA, Six Sigma Black Belt (CSSC), Certified Scrum Master, Admissions Specialist, Hostos Community College (CUNY)
It is the first week of February. Your team has forty open tasks spread across three email threads, two spreadsheets, and a whiteboard nobody updated since November. Somebody is waiting on a document that was supposed to be processed last week. A supervisor asks for a status update, and the honest answer is: nobody actually knows. This is not a staffing problem. It is not a training problem. It is a process problem—and it repeats itself every single semester, like clockwork.
I work in admissions at a college in New York City. I also hold a Six Sigma Black Belt and a Certified Scrum Master credential. For years I assumed those certifications belonged to a different world—the world of tech startups and engineering teams. What I have learned, through applying both frameworks inside a real higher education office, is that the coordination problems crushing service teams are exactly the problems Scrum was designed to solve. The fact that it was invented for software developers does not mean it belongs to them.
What Scrum Actually Is
Scrum was created in the 1990s as a response to a specific and recurring failure: software projects were collapsing because teams tried to plan everything upfront, locked those plans in stone, and then watched reality deviate from the plan almost immediately. The solution was to stop planning in full and start planning in short, focused bursts called sprints—typically two weeks. At the end of each sprint, you deliver something real, review what worked and what did not, and adjust before the next cycle begins.
What makes Scrum different from traditional project management—often called Waterfall—comes down to five things.
- First, teams plan just enough to get started instead of mapping every step before work begins.
- Second, the scope of a project is expected to change and adapt, not remain fixed.
- Third, working output is delivered every two weeks instead of only at the very end.
- Fourth, change is built into the system from the beginning rather than treated as a problem.
- Fifth, progress is shown through actual deliverables, not status reports.
Reading that list, a higher education administrator might think: that describes every semester I have ever worked through. Priorities shift mid-cycle. New directives arrive from central administration while the team is already mid-task. Enrollment targets change. Deadlines compress. The idea that a static project plan will survive contact with an academic calendar is, at best, optimistic.
What It Looks Like in Practice
Consider a concrete example. An admissions office is preparing for an open house event six weeks out. The traditional approach is a long master task list, assigned loosely by role, with a check-in meeting every week to ask who has done what. Items fall through the cracks. Ownership is unclear. The person managing communications does not know that the person managing registration is blocked on a technology issue until two days before the event.
With Scrum, that same preparation runs differently. The team builds a Product Backlog—a prioritized list of every task needed, written as specific, completable items with clear owners. Every two weeks, the team selects the highest-priority items from that backlog and commits to completing them within the sprint. Each morning, the team holds a fifteen-minute standup: What did I complete yesterday? What am I working on today? What is blocking me? At the end of the sprint, the team reviews what was delivered, surfaces any problems, and adjusts the backlog before the next cycle. By the time the open house arrives, there are no surprises—because blockers were surfaced every day, not discovered the morning of.
No software is required. No budget is required. A whiteboard with three columns—To Do, Doing, Done—is enough to start. The entire framework runs on shared visibility and short cycles. Those two things cost nothing.
Why Higher Education Resists It
The most common objection I hear from colleagues is that Agile methodologies are for tech teams. This objection is understandable and also incorrect. Scrum is not a software tool. It is a coordination framework. The reason it was developed in software is that software teams ran into the adaptability problem first, at scale. Higher education is simply decades behind in acknowledging that the same problem exists in our operations.
The second objection is that the academic calendar is fixed, so sprints do not apply. This also inverts the logic. A fixed calendar with predictable high-pressure windows—application deadlines, enrollment periods, orientation weeks—is the ideal environment for sprint-based planning. You already know when your pressure points are. Scrum simply gives you a structure for working toward them systematically instead of reactively.
The third objection is leadership buy-in. Some administrators will see a daily standup as one more meeting. The response is simple: a fifteen-minute standup eliminates the two-hour status meeting at the end of the month. It surfaces problems when they can still be fixed, not after the damage is done.
When Scrum and Six Sigma Work Together
If you have studied Six Sigma, the connection between the two frameworks becomes immediately clear. Six Sigma—specifically the DMAIC methodology—is a tool for identifying, analyzing, and permanently eliminating the root cause of a broken process. It answers the question: why does this problem keep happening, and how do we make it stop? It is deep, deliberate, and data-driven.
Scrum answers a different question: once the process is working, how do we keep the team organized, visible, and consistently delivering? Six Sigma fixes the engine. Scrum keeps the car on the road. Used together, they form the most complete operational toolkit available to a higher education administrator who is serious about sustainable improvement.
The sequencing matters. Use Six Sigma first when you are diagnosing a chronic problem—a processing error that recurs every cycle, a workflow that consistently breaks down under volume. Once the root cause is addressed and the process is stabilized, introduce Scrum to maintain the discipline of delivering consistently, adapting to change, and keeping the team aligned without relying on heroic individual effort.
How to Start This Week
You do not need a certification, a consultant, or a new software platform to run your first sprint. You need three things: a team willing to try something for two weeks, a whiteboard or shared document with a backlog of your current open tasks, and a commitment to a fifteen-minute check-in every morning.
In the first sprint, you will not do it perfectly. Items will be too large, ownership will be fuzzy, and the retrospective will feel awkward. That is by design. Scrum is built for teams that are learning while doing, not teams that have everything figured out before they begin. The second sprint will be better. The third will feel natural.
Higher education administration is not short on intelligent, dedicated professionals. What it is often short on is systems that match the complexity of the work those professionals are being asked to do. Scrum is not a magic solution. It is a structure that makes invisible work visible, surfaces problems early, and builds the habit of continuous improvement into the rhythm of the team. Your office already has the people. Give them a better system to work within.
share