One concept that stuck with me from learning about agile project management (PM) is the sprint. Agile PM is based on principles, and it can be implemented in different ways. It’s a flexible methodology. One agile approach is Scrum, and one of the five Scrum events is a sprint. Think of a sprint as a period, usually a couple of weeks, where a team focuses on a particular task or set of tasks. It’s like a mini-, time-crunched, singularly-focused project in the middle of a project.
This idea stuck with me because one of my challenges is staying focused on a task. I can’t always rely on my brain to think linearly. In fact, I often jump around on a project. Sometimes that’s fine, but other times it’s not because it makes it hard to measure my progress. Sprints require focus, forcing you to say “no” to some things and a strong “yes” to something else.
In my mind, there are so many possibilities of approaching work. And my natural over-achiever tendencies cause me to immediately up the ante. Instead of thinking, how do I get this done in the fastest, most efficient way possible, I like to dream up big, elaborate visions, and I can get lost in my head. While I’m doing this, I’m missing out on time actually spent “doing” and learning and making mistakes. When I do finally settle down, my brain still likes to jump around and think about how to make something sexier. But I have to bring myself back to the task at hand. I’ve experienced this issue in almost every role I’ve had as an adult.
So when I heard about the sprint, which is based on this idea that we agree to do THIS and only THIS for this period, which by default means we’re not doing THAT, it gave me hope. It gave me structure, and it gave me the vocabulary to use.
One of the principles in Agile is that you focus on creating value as soon as possible. For example, if you are building an app, it typically takes 6 months. First, you have to take the idea, draw up a prototype, design the app, and actually develop it. Then, you have to test it, deploy it, and service it. In this scenario, you don’t create value – i.e., the benefit of having the working app – until all of these steps are completed. Using an agile approach like Scrum, instead of waiting 6 months for the app, we can release the app in one month and make improvements over time.
Let’s say we have a 4-week sprint. At the beginning of the sprint, the team decides what can be accomplished in 4 weeks given the constraints around the team’s time and abilities. They can’t release 6 months of functionality in one month, so they decide to release the bare-bones functionality of the app. It might not be sexy, but it’s usable and starts to add value for the intended audience. So in a sprint, the team would look at how to design, develop, test, and deploy one feature in one month. And then, in the next month, they’d do the same.
Applying this to life, we can’t do everything we want at once. As I shared in a previous post, humans are notoriously bad at planning far out in the future. It’s good to have an eye on the horizon, but what we have the most control over now is what’s right in front of us. In a way, focusing on the present is the best way to plan for the future. A real-life example for me is that I want to be an accomplished, amateur pianist who gives small classical music concerts in people’s homes. I want to educate them on the piece, the composer, the period, its connection to today – ultimately, to add some context to otherwise esoteric music and make classical music more accessible. I have a lot of music to learn and haven’t given much thought to making this a reality. But if I want to start now, I can have small recitals for my friends – which I’ve done in the past. These have been on a smaller scale and have helped me improve and fine-tune my approach for next time. In a way, this is what happens on a sprint. And this is why I thought PM, specifically Agile PM, would be an excellent way to track my progress towards this goal.
The Common Blog 