One aspect of Scrum that makes me feel uneasy is the use of the word ‘sprint’ for each of the cycles. I believe that the choice of terminology is crucial, don’t you? Personally, the term ‘sprint’ conveys the idea of making an exhaustive effort for a short period of time. The fact that this agile framework emphasizes this particular aspect can be somewhat confusing. It raises questions like: When do I walk? When do I rest? When do I get time to plan? Referring to each cycle as a ‘sprint’ gives me the impression that I’ll be constantly rushing. Do you share this perspective?
Software development is like a long-distance run. Most of the time, you need to maintain a steady pace—a velocity that enables you to consistently deliver features, maintain your code, and improve your skills predictably and profitably. This rhythm should allow you to adapt to exceptional changes. Occasionally, you’ll need to sprint to meet deadlines or address critical issues. Your overarching goal should be to enhance your performance over time while avoiding the risk of ‘injuring’ yourself—ensuring you don’t burn out!
The way I do it
I’ve discovered that I’ve developed certain instincts through experience. When embarking on a new project or tackling a new feature, I approach it with caution. I open all my senses and listen to my intuition: How do I feel about this? Sometimes, I feel confident and proceed quickly, knowing exactly what’s needed, where, and when. Other times, I tend to move more cautiously, taking a measured approach, as something feels off and I sense the need to address it before proceeding. On rare occasions, my instincts urge extreme caution, signaling danger. I must tread carefully, testing the ground thoroughly before taking any further steps.
You can learn more about your subconscious mind and how developing your instincts over time is a key aspect of gaining proficiency in your work in the book ‘Pragmatic Thinking and Learning‘ by Andy Hunt.
Obviously, I don’t rely solely on my instincts; planning is the central piece of my working routine. Much has been written on this matter, and I won’t attempt to play the role of a life coach, dictating how you should approach your planning, as there is no one-size-fits-all solution. I would, however, like to highlight a couple of things that are important to me:
- Break down things
- Write down things
- Time down things (Find the right time to do each thing)
Don’t bite more than you can chew
You can choose your reason for breaking your work into smaller chunks, but there’s one that you should always keep in mind: because that’s what we, as programmers, do. Our entire craft is based on the concept of taking large, complex problems and dividing them into smaller (and smaller) simpler ones that we can solve. This is the trump card you should play when in doubt, but there are other reasons you can use to persuade your non-programmer coworkers:
- We get more accurate estimations…
- …and we can track the status better.
- We can assign team capacity…
- …and we can rearrange the order or mix with other work.
In the end, the most important thing is that you don’t bite off more than you can chew. Remember that you’ll be more productive if you’re able to live for the next week!
Use your external brain
I’ve observed that people often avoid writing, just like cats avoid water. Personally, I sometimes catch myself composing vague and unrevealing phrases, even though I have a passion for writing. There are moments when we’re not in the mood or in the right mindset for writing. However, this is precisely why you should push yourself to put your thoughts into words. If you don’t feel like writing, it’s likely because you’re not certain how to articulate it. And if you’re unsure how to explain something, it might be because you haven’t fully grasped it.
Writing things down allows you to delve deeper into issues compared to just diving into the work. You can think of it as writing test assertions; your sentences serve as a contract for your code and will later function as documentation. However, don’t limit your writing to just task definitions. Try to document all the steps you’re taking. This information will be highly beneficial later when you need to recall why a task took so long or how to address a similar issue.
Writing things down also helps reduce your cognitive load by externalizing information from your brain, allowing you to fully concentrate on your current task.
Procrastinate
There’s a productivity tip: tackle the most unappealing tasks first to get them done. I mostly agree, but the devil is in the details. I don’t recommend always doing them first. The most important thing to keep in mind is that you should allocate tasks to the right time—when you have the most energy, resources, or clarity to focus. It isn’t necessarily the first hour of the morning; you need to find what works best for your specific context.
I’ve found that procrastination is a built-in feature of our brains that helps us determine the best time to tackle tasks. As part of our instincts, there are times when we don’t feel like doing something, and we tend to gravitate toward smaller tasks, such as fixing bugs that don’t require our full attention.When you find yourself in that situation, don’t be too hard on yourself. It’s likely because you function better in the afternoon when tackling more substantial challenges, or you just need to find the right moment to get into ‘the zone’.
As long as it doesn’t disrupt the rest of your team and doesn’t jeopardize the deadlines, don’t be afraid of a healthy amount of procrastination.
You can do anything, but not everything.
David Allen
There’s another aspect of sprint-minded work: getting used to a narrow scope. I’ve noticed that people working with agile frameworks in general, and with Scrum in particular, often lose sight of the long term. It’s ironic because agile methodologies aim to encourage forward-thinking. People either freeze when their board is empty, unsure of what to do next, or they bury themselves in endless work without taking breaks.
There’s life outside the board
Usually, there are plenty of tasks that are not represented on a card, or to put it differently, an empty board doesn’t necessarily mean there’s nothing to do. Being too focused on moving cards around the board to reach the end of the sprint (iteration) may hinder your initiative to review code, monitor services for issues or improvements, engage in documentation work, or attend to tasks like cleaning up old stories, emails, or other communication channels.
You can take the time to look beyond your team’s work, and even better, look beyond code-related concerns. You can derive significant benefits from understanding your company and its business.
Breathe
If you have a busy backlog, don’t wreck yourself at the voice of ‘timber,’ even if you aren’t exhausting yourself. You need to find time to rest, learn, and practice other valuable skills for your career. If you ever find yourself working as if you’re on an assembly line, picking items from a conveyor belt in a monotonous, rhythmic fashion, it’s time to take a break and look at things with perspective.
I’ve seen hardworking people stuck in the same role for years, while others who are less busy become more productive and advance by acquiring new skills. Being the ox that carries the most load won’t make you a cart driver. Force yourself to allocate time for self-improvement.
And breathe.
Leave a Reply
You must be logged in to post a comment.