This is the first in a series of posts based on my workbook for the Agile Project Management course I teach at the Digital Humanities Summer Institute. Although the original material is focused on humanities research projects, I have adapted it to address a more general audience.
Agile project management is about negotiating the completion of a project from beginning to end while remaining flexible. Being patient and delaying decisions until you have to make them, gathering as much information as you can in the meantime, and then taking action with the information you have, always keeping alternatives in mind in case your first plan of action doesn’t pan out. Just as a fighter shifts from foot to foot to be ready to counter a punch, the agile project manager constantly considers shifts to accommodate any changes in the project’s environment. But it’s about more than just negotiating within the rules. It’s about changing the rules of the game to ensure a more successful project.
We don’t need to use agile management for everything. If we know exactly what we need to do and have the time and money to do it, then we just do it. But if all of the questions aren’t answered, or we don’t have more time and money than we need, or we have a “garden of forking paths” before us, then agile methods can help us stay focused and do those things that are most likely to bring success. Understanding our audience’s needs, creating stepping stones to our goals, scheduling and calendaring, breaking tasks down into smaller tasks, understanding how long they might take, and prioritizing. All of these are valuable, but they become powerful in reshaping even a personal project when brought together into a single workflow.
Which Agile?
Agile means many things to many people. Every team implements it a bit differently, but then, every team is unique. No other team has exactly the same people with the same skills as your team. How you socialize and share the work impacts the kind of agile you find most comfortable.
The agile manifesto gives us a foundation to guide us. We should focus on individuals and interactions rather than processes and tools. Working software rather than documentation. Collaboration rather than contract negotiation. And maintaining flexibility to respond
to change rather than blindly follow a predetermined plan. This doesn’t mean those other things aren’t necessary, but they aren’t as important in delivering a good project.
The agile methods we will discuss in this series are based on a few assumptions about the kinds of projects we might encounter. We assume a deadline, a small team, and a fixed budget. Many of the methods we discuss can be ignored if we don’t have a deadline if our deadline is far into the future, and if we can augment our budget over time. Even without those constraints, we can do agile project management. We just have a lot more flexibility.
I won’t cover all of the theory around agile in this series. Instead, I will share what I have found useful in my experience as a starting point for discussion. With agile, as with jazz, there are no wrong answers as long as you and your team can continue delivering on your project.
Does your team need something else? Are you exploring agile but unsure where to start? Schedule a free consultation, and we can make a good first guess.