Agile and Agile-Like: A Response to the University of Michigan Library

I recently read a post by Melissa Baker-Young, a web project manager at the University of Michigan Library. In her post titled "Agile-like", Melissa addresses some of the common challenges that libraries (and universities, higher ed, etc.) face when embarking on a web or technology project.

These organizations often have a highly talented internal team but need a couple of extra experts to round out the project. Sometimes is hard to find the money for these extra people or extra team(s). And sometimes it’s hard to even find the right people to spend that money on. (UM Library had grant money for this and hired DCE, a third-party vendor — something we often recommend.)

And finally, there is the issue of how to manage the project, align stakeholders and stay on track. This is where the UM Library team adopted Agile.

Michelle writes, “For us, when we’re saying we’re Agile, we mean that we’re allowing ourselves to move forward using the information we currently have, while recognizing that it may need to change as the project progresses, and being perfectly ok with that.

Our approach may look scrappy compared to more well-established Agile teams, but I believe that we are on the right road and that we’ll continue to improve.”

I love love love this section. Here’s why:

Agile is great. It presents an iterative system for development, planning and communication, but it can be a real challenge for some teams to adopt in entirety and I don’t think there is anything wrong with that.

Likely, there are development agencies out there that run Agile as a smoothly oiled machine and I believe there are great benefits to doing that. Accountability, standards, clear expectations come to mind as reasons.

But taking pieces of Agile — say, using Scrum — can help a team stay on track, too. (For other teams, Agile might not make sense at all.)

At Bluespark, we use Agile, but it’s not textbook. We’ve found that reality is powerful and that working with humans in real time and real life is kind of messy. Things change. People change. Projects change. Jobs change. Agile is ideally meant to account for that, but sometimes it just doesn’t.

We work iteratively and in cycles but we adjust our project management for each project and each client. We try to implement structure while embracing fluidity. We work with some of our clients in two-week sprints. For others (and other projects), it just doesn’t make sense.

Our team is remote so we don’t have a physical daily scrum — or stand up — but we video chat on a regular schedule with our developers, project managers and clients. We don’t skimp on communication.

Some might disagree with this “Agile” methodology. They might say,"If you say you’re Agile, you need to be Agile" and I agree, there is value in finding the discipline to do that.

But being Agile isn’t just about merely following a set of rules.

Like the University of Michigan Library, sometimes you have to jump in and just start swimming. This way you find out where the holes are, whose role isn’t well defined and where communication is breaking down. With every cycle, not only does the project improve, but so does your process.

We frequently discuss our consistency with Agile and what changes would improve our project management and development. In this iterative process, we strive to maintain our flexibility and … agility. And that’s an important factor for us.

Is it textbook Agile? Nope. Is it our Agile? Definitely. And we’re constantly working to make it better.

So, bravo for being agile-like.