Skip to content
    April 10, 2017

    Don’t be a Lollygagger!

    I have enjoyed using analogies between baseball and software development in a few of my previous blog entries, so with Major League Baseball’s season underway, there’s no better time than now to write another baseball-oriented blog entry. But don’t fret, non-baseball fans, because this message, like so many others, applies to both life AND baseball.

    In recent years, I’ve observed many software development teams engaged in long-term, multiple-release software development projects. I would classify these as projects incorporating stable, unchanging teams, spanning a year or more and challenged with navigating through fluctuations of tension – followed by calm – which usually accompany projects with multiple production releases.

    An interesting and alarming behavioral tendency seems to have emerged – or more likely, I’m only now noticing it – with enduring, static teams working together on projects or applications spanning multiple releases. This behavior isn’t an obvious, tangible issue like a team member missing meetings. Rather, it’s a human behavioral trait that seemingly emerges unnoticed and isn’t uncovered – if it’s even uncovered at all – until it’s usually too late, after the damage has been done.

    What is this negative tendency you may ask? And what in the world does this have to do with baseball? Well, it can be defined with many words or explanations, but for this blog, we’re using one word: LOLLYGAGGER. Trust me, as you will see, you don’t want to be called a lollygagger, as it’s definitely not a compliment or a term of endearment. And you certainly don’t want to be developing software with or managing a team full of lollygaggers. defines the verb ‘lollygag’ as follows: To waste time by puttering aimlessly; dawdle. This simple definition does not do proper justice to this word.

    Side note: It would also be prudent to mention here that this behavior doesn’t seem to manifest itself on greenfield projects, or short-term engagements with newly-formed teams for obvious reasons – arrangements which usually permeate high-energy and team enthusiasm during the early ‘forming’ stages of team development (see Tuckman’s Stages of Group Development). This would make sense as a lack of enthusiasm is usually not a characteristic of newly-formed teams.

    So, this odd linkage came to mind when the movie Bull Durham appeared on television a few nights ago, which – aside from providing the vision for this blog entry – is one of my all-time favorites. Critically acclaimed as one of the greatest American sports movies of all time, Bull Durham is a must-see for any baseball enthusiast. The movie is based on one person’s experiences in minor-league baseball and depicts players and fans of the Durham Bulls, a minor-league baseball team residing in Durham, North Carolina.

    One gains a TRUE SENSE of how lollygagging can hurt any team watching one of my favorite scenes in the movie which casts “Crash” Davis, the wise, veteran catcher and the Bulls’ manager, known as “Skip” (of course). The Bulls are playing awful baseball, mired in a long losing streak, and the manager has run out of patience and ideas. Which takes us to the scene inside the Bulls locker room after yet another painful loss:

    Skip: “I don’t know what to do with these guys. I beg… I plead… I try and be a nice guy… I’m a nice guy.”
    Crash: “Scare ‘em.”
    Skip: “Huh?”
    Crash: “Scare ‘em. They’re kids, scare ‘em. That’s what I’d do…”

    After a chuckle, and now armed with this ingenious managerial advice, “Skip” proceeds to forcefully assemble his unsuspecting group of apathetic ballplayers into the shower area, throwing an entire rack of baseball bats into the shower after them, which certainly draws their attention (and those watching the movie). “Skip” then barks out an epic rant that would make Earl Weaver proud:

    Skip: “You guys… You LOLLYGAG the ball around the infield. You LOLLYGAG your way down to first. You LOLLYGAG in and out of the dugout. You know what that makes you? Larry!”
    Larry: “LOLLYGAGGERS!”
    Skip: “LOLLYGAGGERS. What’s our record, Larry?”
    Larry: “Eight and 16.”
    Skip: “Eight and 16. How’d we ever win eight!?!”

    So, in summary, a hilarious scene from a baseball movie taught me early on that lollygagging is not a good thing. I am now seeing that it is also a bad way to start off the early stages of your software development project. Think about it – as a team, once we clear that release hurdle, our instinct is to stop, take a deep breath, and relax. We just hit a major milestone, and more than likely the team worked some intense hours, days, weeks and sprints leading up to the actual release. (No matter how good your team is or how well you apply agile techniques, the days leading up to a release are ALWAYS more intense than those at the outset of a project.)

    Picture the scene: our big release is deployed over an entire weekend, and everyone arrives to work on Monday. Whatever velocity, urgency and momentum generated and sustained through the prior release has seemingly dissipated into thin air. Because our next release is several weeks or months out, a feeling of tranquility sets in, as if the level of urgency no longer exists. We have now become…wait for it…OH NO! LOLLYGAGGERS!

    This period of relaxation, or lollygagging, poses many threats to the next phase of the project.

    • That next release schedule – which was planned and completed last week and is now posted on the team room wall for everyone to see? Unfortunately, that new release schedule does not include any extra time for and does not tolerate relaxation, tranquility, or LOLLYGAGGING in the early sprints of the next release.
    • Due to the team carryover (with little or no change in personnel) the work to be done in Sprint #1 of the succeeding release is also likely projected based on established velocity from earlier sprints (i.e., the previous release). A slow, unproductive start to the first few sprints will undoubtedly result in a negative cascading effect on the entire release. For example: your release plan calls for 200 points with another production deployment after 10 sprints, because your team has proven time and time again this is an achievable goal (i.e., team velocity ~20 points). Your first two sprints start slowly and end up totaling 20 points, which already puts the team in trouble and in catch-up mode. Nobody likes being in catch-up mode. And catch-up mode tends to have a snowball effect.
    • Unless the release plan provisions for it, don’t allow carryover from the previous production deployment (or any associated issues or complications) to bleed into the early phases of the new release. Lollygagging will set in if team members continually remain in the mindset of the preceding release – in other words, looking back and not forward. Make sure the page is turned quickly on the weekend of the release (i.e., over to product support) and not turned slowly in the following few weeks.

    As mentioned earlier, this behavior isn’t usually noticeable early on, but in those last few weeks before the subsequent deployment, when things become hectic and crazy again, everyone will wish they all hustled a bit more in the early weeks of the project.

    Don’t get me wrong – celebrate the occasion! We’re not robots, and I’m a firm believer in recognizing and/or celebrating milestones at the end of a sprint or even better, after a successful production deployment. Those team milestones and achievements that we recognize working as teams are one of my favorite concepts of Scrum. But the party, or I should say, ‘mental break’, should not last for four weeks.

    Here’s another way to think of it, and yes, we’ll use another baseball analogy. There is a baseball maxim which is often spoken at this time of the year. When a baseball team with high expectations opens the season with a poor start, you’ll often hear the following quote (or something similar):

    “You can’t win the pennant in April, but you can certainly lose it.”

    Keep that in mind when your next release starts – you can’t guarantee a successful project or production deployment in the first couple sprints of your new release, but if you come out of the gate slowly and LOLLYGAGGING, things can certainly come off the rails in a hurry. And everyone will be paying the price a few months later as the release date draws near.

    The solution is simple, right? Make “Skip”, “Crash” and me proud, and just DON’T BE A LOLLYGAGGER!

    Pete Rose, aka “Charlie Hustle”, was certainly not a lollygagger. He surely wouldn’t allow any of his teams to lollygag through the first few sprints of a release.                

    The Durham Bulls, on the other hand, captured the true essence of lollygagging. I can assure you that in this scene, only one or two people were actually concentrating on baseball.

    More from the blog

    View All Blog Posts