A self-guided mini-course · about 10 minutes

Agile Techniques for Getting Your Work Done in Teams

Agile is a popular way of managing projects, built on close collaboration and working in iterations. It's rooted in software development — but its techniques are just as effective in far less technical contexts.

Enrique A. Diaz · Architecture & Engineering, Library Technology Services, Harvard University
Adapted from a talk at the HighEdWeb Annual Conference, September 2024

Swipe, tap the arrows, or use keys, at your own pace. Tap Contents anytime to jump around.

Before you begin

What you'll take away

These ideas come from years of applying Agile — iteration, continuous improvement, empowerment, collaboration — to real teams and projects. The goal: leave with things you can adopt and share with your own team.

1 · Agile in a nutshell

Where Agile came from, and how it differs from traditional project planning.

2 · The Scrum

A simple, repeatable rhythm for team work — no software required.

3 · The check-in

The single most valuable habit to steal, and the three questions that power it.

How to use this deck: everything you need is on the slides — look for the “Go deeper” panels for extra context when you want it.

01

Agile in a nutshell

The idea and strengths of Agile methodologies.

The easiest way to understand why Agile emerged is to start with the conventional approach most of us already know.

(Yes, that's a waterfall. Hold that thought.)

Part 1 · Agile in a nutshell

The traditional way: Waterfall

The classic approach is perfectly logical: break your big idea into phases, and finish each one before the next begins.

REQUIREMENTSConfirm what the end product should do and be
DESIGNShape the solution that meets those requirements
IMPLEMENTATIONBuild the product based on the design
VERIFICATIONTest it — did you stay true to the plan?
MAINTENANCETake care of what you built
Why “Waterfall”? Work flows downhill — one phase does not begin until the goals of the previous phase are complete.

Part 1 · Agile in a nutshell

The Agile loop

Agile, by comparison, is not so different. You still gather requirements, plan the end result, design, develop, and test. Then you release — deliver something real to your audience — and track how it does.

DEVELOP DESIGN PLAN RELEASE TEST REQUIREMENTS TRACK Agile

Then you go around again — and again.

Part 1 · Agile in a nutshell

Waterfall vs. Agile — so what's the difference?

Look closely and they involve essentially the same components. One's a stagger-step, the other's a loop — in fact, Agile even adds a couple of steps. So what?

Waterfall

Agile

DEVELOP DESIGN PLAN RELEASE TEST REQUIREMENTS TRACK Agile
The difference is time. Everything Waterfall does happens in Agile too — just over a much shorter window, again and again.

Part 1 · Agile in a nutshell

Small slices, repeated

You don't crunch all that work into a smaller window. You take on a small, manageable piece of each phase — and repeat the whole process.

  • More delivered in the same amount of time.
  • Multiple opportunities for feedback that shape the project as it goes.
  • A better end product, informed by everything you learned along the way.

So how do you actually get it done? One proven way is called the Scrum.

02

The Scrum

One example of why Agile works as well as it does.

Go deeper · Why is it called a “scrum”?
The name comes from a 1986 paper in the Harvard Business Review comparing high-performing, cross-functional product teams to rugby teams using the scrum formation at the start of a play: coordinate the team without a rigid long-term plan, drive toward attainable short-term goals, then repeat toward the next set — like playing toward a goal in rugby. Except with fewer broken bones. Hopefully.

Part 2 · The Scrum

Scrum in a nutshell

Six moves, then repeat:

1

Build the backlog

The team lead organizes a to-do list of everything that needs to get done. Everything.

2

Plan the sprint

The team pulls a small portion from the top of the list, breaks the tasks down, and decides how to get it done.

3

Sprint

A stretch of time, chosen by the team, where the work happens — with regular check-ins to assess progress.

4

Wrap up

By the end, the work should be potentially “shippable” — demo-able, ready to hand to a user or show a stakeholder.

5

Review & retrospect

What went well? What should change next time? Shoutouts and high-fives all around.

6

Do it again

Choose the next portion from the top of the backlog and begin anew.

Go deeper · What does “breaking the work down” look like?
Say you want to tackle something complicated that's riddled with unknowns. Make investigating those unknowns the goal of the sprint — the answers then inform the work of the next one. Learning counts as progress.

Part 2 · The Scrum

The check-in

You may have noticed check-ins inside the sprint. They're the heartbeat of the whole thing.

  • Frequent and deliberately short. It's often called a “stand-up” — short enough that nobody needs to take a seat.
  • Mitigates project stall-out. Blockers get raised the moment they appear, before any part of the project quietly grinds to a halt.
  • Brings the whole team's knowledge to bear. When an obstacle surfaces with everyone present, creative ways forward emerge — including how a lead can clear the path.
Format doesn't matter. In person, over Zoom, or asynchronously in Slack or Teams — a check-in works anywhere your team does.
A Zoom meeting with eleven team members in a video grid
A real stand-up over Zoom — short, face to face, everyone present.
A Slack project channel where team members post morning check-in updates
The same ritual, asynchronously — check-ins posted to a Slack channel.

Part 2 · The Scrum

The check-in questions

Three questions are all it takes for a team to connect in meaningful ways:

  1. 1What have you accomplished so far?
  2. 2What will you accomplish today?
  3. 3What's preventing you from making progress right now?
If you adopt just one thing from this deck, make it the check-in. It invites the collaboration and empowerment that make the rest of the process productive.
Try it yourself
Answer the three questions for a project you're working on right now. Question 3 is usually the revealing one — naming a blocker out loud is the first step to clearing it.

One last thing

Do what you can with what you have.

A lack of resources doesn't have to mean a lack of progress.

Recap · Bring it home

Small steps. Short loops.
Real momentum.

Everything in this deck comes down to four habits — and every one of them is yours to start this week.

1

Work in small slices

Deliver early, deliver often. A short cycle repeated beats a long plan perfected.

2

Let feedback steer

Every trip around the loop is a chance to course-correct — build with your audience, not just for them.

3

Keep goals attainable

Facing unknowns? Make investigating them the goal. Learning counts as progress.

4

Start with the check-in

Three questions, kept short, standing up. The easiest habit to adopt — starting tomorrow morning.

No budget. No mandate. Not a single line of code. Just a team willing to work in the open, a little at a time.

Pick one. Bring it to your next team meeting.

Thanks!

Keep in touch & read more

Contact: enrique_diaz@harvard.edu

Works cited

  • Vandersluis, C. (2014). Apply agile methodology to non-software enterprise projects. PMI® Global Congress 2014 — North America, Phoenix, AZ. Project Management Institute.
  • Manifesto for Agile Software Development. agilemanifesto.org
  • Sutherland, Jeff, and Ken Schwaber. “What Is Scrum?” Scrum Guides, Nov. 2020. scrumguides.org

Further reading

Agile in non-software contexts

  • Rigby, Darrell K., Jeff Sutherland, and Hirotaka Takeuchi. “Embracing Agile.” Harvard Business Review, vol. 94, no. 5, May 2016, pp. 40–50. hbr.org
  • Conforto, Edivandro C., Fabian Salum, Daniel C. Amaral, Sérgio Luis da Silva, and Luís Fernando Magnanini de Almeida. “Can Agile Project Management Be Adopted by Industries Other than Software Development?” Project Management Journal, vol. 45, no. 3, 2014, pp. 21–34. doi:10.1002/pmj.21410
  • Gustavsson, Tomas. “Benefits of Agile Project Management in a Non-Software Development Context: A Literature Review.” PM World Journal, vol. 5, no. 8, Aug. 2016. pmworldlibrary.net
  • Stoddard, Morgan M., Bill Gillis, and Peter Cohn. “Agile Project Management in Libraries: Creating Collaborative, Resilient, Responsive Organizations.” Journal of Library Administration, vol. 59, no. 5, 2019, pp. 492–511. doi:10.1080/01930826.2019.1616971
  • Wu, Yaling, Alexandra Guimaraes, and Zheng Wang. “Product Owners at Hesburgh Libraries: Increasing Stakeholder Engagement and Accountability Through Continuous Organizational Enhancement.” Journal of Library Administration, vol. 60, no. 7, 2020, pp. 695–713.
  • Denning, Stephen. The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done. AMACOM, 2018.

Agile for individual contributors

  • Benson, Jim, and Tonianne DeMaria Barry. Personal Kanban: Mapping Work | Navigating Life. Modus Cooperandi Press, 2011. personalkanban.com
  • Meier, J.D. Getting Results the Agile Way: A Personal Results System for Work and Life. Innovation Playhouse, 2010. gettingresults.com
  • Matarelli, Maria, and Peter B. Stevens. Personal Agility: Unlocking Purpose, Alignment, and Transformation. Business Agility Institute, 2022. personalagilityinstitute.org
  • Sutherland, Jeff, with J.J. Sutherland. Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business, 2014.

Presentation resources

Type: DM Serif Display & Montserrat (Google Fonts). Photography from the original talk: Adobe Stock, Unsplash, and the author.