Archive for November, 2020
For several weeks, I’ve had the following written on my whiteboard:
I’ve been reading a lot of books. But why? Just to know more? But what do I do with that knowledge?
I can find people who could be helped by the knowledge and say what I’ve learned to them.
Or I can use that knowledge myself and actually do the things I’ve read about. Now, that’s a great idea; I get to put it to practice, gain experience myself, and be even more helpful to others.
I can also do all of those things. Maybe I’ve just read about something that enticed my curiosity, but I’m unsure on how to put it to practice. Well, if I share it with others, maybe somebody else is be able to help me by sharing their own ideas or experiences on the subject (This is one of the things we do weekly at the Virtual Brown Bag, by the way).
Sometimes we may do something before we actually know much about it, of before we say it to others. Sometimes we may say something but never do anything about it.
Knowing is important. Saying (sharing with others) is more important. Doing is even more important. But they don’t always happen in that order.
Notice the title doesn’t say Scrum “Software” Projects, because I believe Scrum can be applied to many different types of projects. Having music and motorcycle riding as the other passions of mine, I find myself drawing comparisons and reapplying learnings where I see fit.
In a talk about building trust through delivering results in Scrum software projects, analogies with hitting the apex at a race track have come up, and I felt I had to expand on that idea. So for this post, I’ll consider a software project, but again, the ideas can be applied to many types of scrum projects.
I’ve only started learning about apices and race lines when I started riding a motorcycle at a race track in 2017, so my comparisons here come from my understanding on the subject as of November of 2020. As I learn more, I may need to update this post in the future.
If you’re a fan of races (motorcycles or cars, it doesn’t matter), you are most likely aware that racers know how to hit an apex consistently and why they should hit them.
Consistency is key; hitting the apex consistently, lap after lap is extremely important. Hitting the top speed on a straightway isn’t as important as hitting consistently high average speeds, which yield fast lap times.
Reaching 200mph on the straight and then running off track isn’t the most efficient way to turn fast laps (not to mention you might crash when you run off). Working crazy hours during a Sprint to deliver a high number of story points isn’t an effective way to turn good quality software and keep doing it lap after lap; I mean, sprint after sprint (not to mention you may crash; I mean, get burned out).
The apex is typically the slowest part of a corner. The soonest you can get to WOT (wide open throttle, which means you’re using the vehicle’s fullest acceleration potential), the faster you can get to the next corner. But then, you also need to know that you will have to slow down in order to make that next corner. If you’re looking down to the speedometer to keep marvelling at how fast you’re going, chances are that you will be running off track. If we keep solely looking at number of story points, we may lose track of where we’re going.
In order to find the proper race line, with the respective apex for each turn, we need to analyze each turn backwards. We need to know what comes after each turn to be able to plan a strategy for getting in and out of the corner as fast as possible; if turn 2 is a slow hairpin, then we may never get to WOT coming out of turn 1. If turn 4 preceeds a long straightway, then we need to make sure we exit that corner as fast as we can, getting to WOT as soon as possible.
However, opening the throttle too soon, may cause us to run wide, creating a need to slow down, before accelerating to the full potential (a process that causes loss of precious time).
In a motorcycle, if we open the throttle too much too soon, it may cause loss of traction. Depending on how we handle the situation, when the bike regains traction, it may send us on a trip to the moon and back. Not pretty. How do I see that in a scrum project? Maybe we’re forcing performance optimizations when it’s not the right moment?
Back to planning the corner backwards: we need to see what’s coming. We need to have a vision. We plan for it. Then we execute it (by riding laps). As we do, we look ahead, through the corner.
We may misjudge how much speed we can take into a corner and brake too much. Next time around, we brake a little less.
We may not have good reference points (brake points, turn in points, apex, exit points) around the track to help us assess our speed and strategies. On every lap, we stay aware of those things, so we can fix it next time. Remember sprint retrospective meetings?
Such approach can only work if we are not going recklessly around the track. If we’re riding without control, we will not be able to evaluate our execution; we won’t learn anything from it. So we can’t improve it. We can’t come up with better strategies.
Only hitting the apex isn’t enough. Racers have different strategies for hitting the apex. If they’re trying to make a pass, they may decide to take an early apex, so they can carry more speed into the corner, hopefully passing the other rider, but at the expense of coming out ot the corner slower.
On the hand, if they’re trying to turn consistently fast laps, they may take a late apex, where they carry less spead into the corner, but are better placed to accelerate harder out of it.
See the riders in the photo below: some are trying to pass, some are planning to pass, some are trying to avoid being passed. Their plan to hit the apex varies based on their desired next result (turn a faster lap to stay ahead of the others, get closer to the rider in front and set up for a pass, etc.)
Each lap is a sprint. One fast lap does not guarantee a race win.
Each race is a release. One race win doesn’t guarantee a championship win.
Consistency is key.
Vision, plans, execution, evaluation, tweaks, repetition, strategies, using them accordingly, focus, flow. Wait, am I describe racing or a scrum project?
Image source: Pixabay
There are tons of books and resources about time management. Time is important; one can always make more money, but not more time. We all have the same 24 hours each day, so managing how we use our time is very important, indeed. However, time is not everything.
Even in the unlikely event of having a lot of time in our hands, what if we don’t have the energy to make anything with it? So, energy management is equally important. But time management and energy management are not everything.
We may have time, we may have energy, but what if we don’t have focus? Without focus, we’re likely to deplete our energy and waste our time.
If we have time, we can find ways to replenish energy and focus.
If we have focus, we can find ways to better use our time and and energy.
If we have energy… you got the idea!
Time, Energy, and Focus management. Finding the proper balance between those three points allows us to get more meaningful things done.
Another month full of Virtual Brown Bag meetings in the books and the variety of topics keeps increasing.
Check out what we’ve been up to in October and join us to participate in the conversations as well! Every Thursday, 12-1pm Central Time.
We talked about Microsoft certifications, past and recent experiences. We also spent some time talking about custom matchers in Cypress.io, and security-related static analysis tools.
Great discussion remembering the Alt.NET movement, and also talking about architecture katas.
Obs and PPT automation, Books (Righting Software, .NET Architecture), DDD, Event Storming, CQRS, REST… great conversation!
Some more talk about Mmhmm, anti-fatigue mats, home-office setups, nerves-project.org, IoT, Elixir, micro-services and data for dashboards, AWS and AWS Amplify.
Mmmhmm (virtual camera, setup, experiences), EICAR test string, Spam Pull Requests, things we put in the resumes, databases: when to start thinking and making decisions about them…