Sprint Gaps: A Weekend for Your Sprint

The first article in this series addressed how to fit sprints to business context, with the analogy that people naturally change their routines when they go on vacation, almost without thinking about it. This second installment will talk about intentionally bringing the breaks people take in personal life into software engineering schedules, in a way that makes teams more productive.

In a perfect world, software backlogs would be forever neatly groomed, maintained and prioritized. Features would always be delivered the right way, the first time. Long-term goals would be balanced with short-term goals. There would be no quick hacky fixes, and technical debt would not accumulate. Of course, nobody is perfect. These things don’t happen unless they get prioritized. But what if these things could occur without managers having to explicitly prioritize them? What if they passively became part of the process?

Sprints are a way of wrapping software delivery into predictable units. Sprints exist mostly for the business, not the programmer. There’s no reason why a programmer needs sprints for her own sake, other than to accomplish two things: establish a deadline, and ensure that work is adequately described and scoped into doable chunks no longer than two weeks long. Neither of those goals requires a sprint. So, sprints are a mechanism of control for the business. They help ensure that known chunks of software will be delivered (and evaluated) at short, predictable intervals, which is preferable to working on long and notoriously error-prone estimates and timelines.

If predictability is what the business values, then what does the programmer value? Anecdotally, there’s one job quality that comes up often when talking to experienced programmers, which is autonomy. Autonomy in terms of both what one focuses their efforts on, as well as how they manage their time. The business’ control mechanisms, then, are at odds with the desires of programmers. Considering that another top and growing concern of programmers is burnout, there has to be a compromise. Promoting autonomy and preventing burnout are key to maintaining employees’ happiness, sanity and ulitmately, productivity.

Consider balancing business and programmer needs by building a small gap of a day or two in-between sprints. If a sprint is typically ten working days, then a gap-enhanced sprint would be eight or nine days. A gap-enhanced sprint might start on a Monday and end Wednesday of the following week. That additional day or two (e.g. the final Thursday and Friday) can be designated for a number of rejuvenating and forward-looking activites:

  • Reflecting on sprint demos, incorporating feedback into the sprint backlog
  • Reflecting on retrospective next-steps, and incorporating them into team context and process
  • Reporting out and up on accomplishments to stakeholders, beyond what occurs in Demos
  • Long-term planning
  • Personal or small-group projects for learning and R&D
  • Training and professional development
  • Workshops
  • Writing blog posts or prepping conference talks to get the word out on the company’s work
  • Paying down technical debt or doing work that scratches an itch
  • Running a hackathon
  • Team building
  • Writing up personal accomplishments
  • Team “Fixit” days

So many things are essential to keeping employees growing and happy, while also tending to the longer-term needs of the product and the business. Taking technical debt as an example, sprint gaps can keep this commonly deprioritized but highly important work from falling through the cracks. It’s generally hard to get technical debt on the backlog in the first place, and to convince stakeholders that technical debt tickets should be prioritized into a sprint. If this “unplanned work” is left to be done side-of-desk, it can bring unpredictability to sprints, because programmers will work on it whenever they can, sometimes to the detriment of the sprint. On the other hand, things will run more smoothly if the time between sprints is explicitly blessed to take care of all the seams and loose threads by which the business could unravel.

The mostly likely business objection to sprint gaps is that less work will fit in a slightly shorter sprint. There may be some truth to this, but given less time in a sprint, many teams will simply waste less time during a sprint. The adage known as Parkinson’s Law, tells us that “work expands so as to fill the time available for its completion.” In addition, given the extra time for employees to decompress (see especially the 2007 article from Google linked above), the difference in planned output is likely to be negligible. Also, the additional investment in technical debt, documentation, etc., is more likely than not to improve team velocity during sprints, which will be a net benefit to the business in the long run.

Despite all the possibilities listed above, some more structured, some less, engineering managers should be sure not to over-schedule the sprint gaps. If the goal is to balance control with autonomy, one should make the assumption that developers will focus on the right things to work on in their sprint gaps. For instance, on a team that I managed a few years ago, our developers had to split time across multiple projects, so they used their sprint gaps to perform self-directed maintenance and bug fixes on the projects that weren’t currently prioritized in a sprint. The developers chose their own gap priorities, and it made them happy, and it kept the clients happy, too.

Sprints are not the be-all and end-all. They are a way of time-boxing prioritized work. Give work a “weekend” gap to ensure the health of employees, products and culture. Your business will be better for it.

Sprints Like Beach Vacations: Adapting Routine to Context

It’s fairly standard for Scrum ceremonies to be arranged according to the work week. Sprint Planning and Kickoff on Mondays, grooming sessions in the middle of the week, Sprint Demo and Retrospective on Friday. But is this the best sprint alignment for your team?

When planning team sprint ceremonies, take a lesson from vacationing on the beach. What do we do at the beach? There are two types of vacationers: outing goers and beach-sitters. I’ll speak to the latter, since that’s what I know best. Beach-sitters, as we are in my family, go to the beach to sit, swim, and snack. A typical daily schedule looks like the following:

  • Wake late
  • Don a swimsuit
  • Sit on the beach, swim, and snack until late afternoon
  • Come in, shower
  • Get dressed in clean clothes for the evening
  • Eat a leisurely dinner
  • Go to bed

Notice that beach days are inverted compared to a typical personal routine of showering and dressing in the morning. If the beach goer puts on fresh clothes every morning and fresh clothes after showering before dinner in the evening, they will go through at least two outfits daily. Not very efficient! Fresh clothes donned each evening, and the evening’s slightly-worn clothes donned the next morning make for a much more practical routine. When in Rome…

So how does this relate to sprint teams? There are many reasons why one might want to start and stop sprints on days other than Monday and Friday. These reasons can be roughly bucketed into the following categories:

  1. fixed concerns: e.g. weekends and holidays
  2. variable, but semi-predictable concerns: e.g. PTO, WFH, all-hands
  3. stakeholder concerns: e.g. standing executive meetings and availability
  4. collaborative concerns: e.g. adjacent team sprints
  5. continuity concerns: e.g. at-work time to think and plan

Having identified these categories, how do they apply? Fixed, variable-but-predictable and continuity concerns are generally good reasons to not schedule major sprint ceremonies for Monday and Friday, while stakeholder concerns will vary according to the company and executive context. Collaborative concerns can be more complicated to address. For example, say you have two teams: design and engineering, working on the same product or feature. Design has to be a step ahead of engineering, so when engineers kick off implementing a feature, there already exist designs ready to be translated into code. It’s also common for collaborators to be present at their sibling team kick-offs or demos, so it’s good to stagger their sprints to avoid standing conflicts.

Continuity concerns are also more complex. Look for a follow-up article regarding Sprint Gaps, which will talk about how to give your team time to recover from one sprint and be ready to thoughtfully start the next. Ending one sprint on a Friday and starting the next on a Monday can be a great way to lose continuity, flying by the seat of your pants from sprint to sprint.

That is a lot to weigh, and good stewardship of a project team is no trip to the beach. There are pros and cons to any sprint alignment. However, decision-making grounded in the values of per-sprint predictability, sprint-to-sprint continuity, and cross-team/stakeholder collaboration should result in a workable, or better yet an optimal, solution. But if you need a tangible reminder of how to flex your schedule to fit the context, I recommend booking a flight to your favorite tropical destination.

Tech Companies and Startups in Montgomery County

Update, 9/16/2019: 1776 is expanding to North Bethesda.

Bethesda and Silver Spring, MD, are truly up-and-coming areas. Great for walkable and metro-accessible entertainment and restaurants. They are rapidly becoming more dense, urban, and with the opening of the Purple Line approaching, more connected. What they lack, however, are cutting-edge, high-paying technology jobs.

These areas are ripe with well-educated populations, with a mix of ages and experience, young and old. Why they are not a more popular destination for startups and technology companies to place their businesses is a mystery. Similar suburban areas in Virginia, such as Arlington (especially Clarendon), Tyson’s Corner, and Reston, have had a huge burst of technology startup activity over the last ten years. Montgomery county’s urban areas, if anything, have likely lost tech jobs, e.g. with the departure of Discovery from their Silver Spring landmark building.

One promising development is the slow but steady growth in co-working spaces available in Bethesda and Silver Spring. These may bring new, nascent talent and budding enterprises to the area. But alone, they will not be enough.

My fellow technologists in Montgomery County lament the need for us to commute into DC, or worse, brave the American Legion Bridge daily, in order to get jobs working with newer technology, good workplace cultures, and competitive market wages, with which to support our families. One could even posit that the terrible traffic in the region is exacerbated by the imbalance in tech jobs between VA and MD, made worse by the single choke point that is the 495 bridge. Zero practical public transit options exist to get us MD residents to our jobs in VA. The conversation in the media focuses on the roads and the transit. But what about the location of the jobs? There was a bright spot when Amazon was considering Montgomery County for the location of their HQ2. Finally, there might be an anchor to bring more tech jobs this side of the Potomac. But alas, we lost out to Virginia once again.

What few tech companies do exist in Montgomery County can be hard to find. A few years back, I wrote one of my more progressive county council members, Hans Reimer, to ask whether he had a list of technology startups in the Bethesda area. To my surprise, the answer I received was that no-one on the council has been tracking this information. Since a list hasn’t been forthcoming from the county council or local media, as part of this post, I am compiling and hosting a list of local Montgomery county startups and tech companies.

My criteria for this list include that technology be a major function of the company, that the available jobs be for new software development and not just IT, and that the company’s primary business is not government contracting. The company does not need to have its headquarters in the county, but should have a major office located there. I intend to keep this list up to date and as comprehensive as I can, so please DM me on Twitter or leave a comment here with additions or changes. For now, it is a work in progress, so please contribute if you have anything to add.

Bethesda

  • Xometry: Manufacturing on Demand
  • HelioCampus: Education Analytics and Visualization Platform
  • RightEye: A commercialized eye-tracking solution for general healthcare and wellness
  • ProQuest: research and learning software for libraries and education
  • Salsa Labs: Supporter Engagement Platform for Non-Profits

Silver Spring

Rockville

  • Bethesda: video game developer
  • Speak Agent: evidence-based academic language learning platform