The Secret Non-Engineering Superpowers of Technical Teams
Part 1: Sprints
Photo by Eden Constantino on Unsplash
Since I recently wrote about why you should care about building strong processes for your organization, I’m sharing some processes that have worked well for me in the past. Here I’m focusing on sprints. As you read, keep in mind that there’s no one right process -- it always depends on your organization and your needs. So while these may be a jumping off point, they aren’t a substitute for doing your own user research with your team.
Working in sprints can help any team in your organization. When non-engineers hear the term Agile they sometimes run, but at its heart Agile is a project management methodology. Although it was designed for software development, it has many useful lessons for any team that wants to iterate and learn from its mistakes. And since your non-technical teams are less likely to already be doing this, these processes may even have a bigger impact there.
The Benefits of Working in Sprints
Sprints are chunks of time dedicated to working on tasks selected beforehand. The benefits of sprints are:
More predictability: People will be working in shorter time-frames than those often envisioned when setting company goals. Also, because of the shorter timeframes, you can be much more granular in your planning, even allocating time down to the hour.
More planning and fewer interruptions: By committing to a sprint, you commit to both plan for the next sprint and to only interrupt people during the sprint if there’s a true emergency.
Rapid iteration and growth: People often assume rapid iteration refers to output, e.g. software or content. And sprints do facilitate this, but they also facilitate rapid iteration on team processes and, because they build in feedback, rapid individual growth.
Sprint Cadence
So, what’s the right amount of time for your sprint? I recommend beginning with 2 weeks or shorter so that people can get comfortable with the process and you can make any needed changes. Once people are comfortable with working in sprints, I recommend using these guidelines when picking a timeframe:
People can generally stick to it. It should be a timeframe where you’re comfortable having everyone committed to those tasks unless there’s an emergency.
People can estimate how long a task will take and learn from their estimates. Output won’t always match the estimates as no one is a perfect predictor, but people should be able to break down tasks by number of hours and then allocate their time based on the hours in the timeframe.
The pace matches your iteration speed for output -- if your team is creating and posting new content every few weeks, the sprint cycle should reflect that.
The team should be able to remember the previous cycle well enough to identify what did and didn’t work so they can improve (see below, “Retrospectives”).
Sprint Planning
Before the sprint, you’ll want to hold a planning meeting with your team leadership and any key company stakeholders. For example, I’ve seen engineering sprint planning between the engineering team lead and the product lead, or between engineering, product and the CEO. Basically whoever needs to be aligned on what your team will be doing for the duration of the sprint.
Sprint Kick-off
On the first day of the sprint, you’ll want to run through the sprint tasks with your team or teams -- whoever will be involved in the sprint. If you have a stakeholder who you’ll need to explain tasks (e.g. a product manager for engineering sprints), they should be at this meeting too. A few key things should happen either at this meeting or directly after:
Task assignments: You and your team decide who will work on what during the sprint.
Time estimation: Each team member should estimate how long their tasks will take. If uncertain, the person can get input from teammates or from you at this meeting. By estimating at this meeting, everyone will get more practice and hopefully start getting more accurate. And at the end of the sprint you can review to see if anyone consistently skews in one direction.
Task break-down: By the kick-off you should have your list of tasks as well as whatever detail people will need to break them down further. At the kick-off, I like having people break down their tasks. For engineers, this could be a more detailed specification. For non-engineers, it could be a project plan. Either way, the goal is for people to get experience breaking down tasks, while having you and the team for feedback, and having you as a guardrail if it sounds like someone is planning for more work than is needed.
Stand-Ups
If you work at a software company, you’ve probably seen the engineering team doing daily stand-ups. These are short meetings (usually 15 minutes or less) where people share what they’ll be working on that day and/or what they’ve completed that day or the previous day.
I don’t believe stand-ups are always necessary, even with engineering teams. Instead, I think it’s very dependent on the team and the people on that team. If, for example, your team is small, each person has their own task that doesn’t impact others’ work, and everyone already knows what everyone is working on, you probably don’t need daily stand-ups. They are more likely to be needed when working on projects with a lot of coordination, especially if that coordination isn’t already happening elsewhere.
When deciding whether to do standups and how often to do them, also consider the personalities of the people on the team. If you have many introverts who prefer communicating via slack, you probably don’t need daily stand-ups. If you’re a bunch of extroverts who’d rather just talk, you might as well do the stand-up, even if it ends up serving more of a team-building function.
Retrospectives
Make sure there's time after every sprint to reflect on what worked and what didn't. To get the most out of this, I recommend a different format from your regular meetings -- one that’s more similar to brainstorming meetings (this is also what I’ve seen most engineering teams do). Taking this time to reflect allows you and your team to iterate rapidly on your own processes, so that you’re even more efficient in the next sprint.
For your retrospective, start by deciding on a few categories for the retrospective. You could do “worked well, didn’t work, kinda worked” or “start, stop, continue.” If you want to mix it up, Fun Retrospectives has a lot of ideas. After defining the categories, provide each person time to write out their ideas on post-it notes. If you’re remote, one tool I like for doing this virtually is Miro. Then, go around the room allowing each person to add their notes to the board and explain their thinking.
Two notes to make sure you achieve your goal of learning from the previous sprint and improving for the next one. First, everyone needs to feel safe, so they need to know that information will be used only for the future, and that they won’t be punished for sharing. One tool I like here is starting with Agile’s retrospective “prime directive,” from Norm Keith:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
Second, you want the information you get to be as unbiased as possible. So make sure that you and anyone else in the room in a leadership role shares last rather than first -- otherwise people may try to share what you want to hear rather than what they are thinking.
At the end of the retrospective, genuinely thank everyone for sharing, summarize key themes, and decide on a few action items to commit to for the next sprint. By summarizing, you’re showing your team that you hear them, and by committing to ideas, you’re showing the team that their ideas matter.
---
If you try using sprints, please let me know how it goes. If you’re interested in guidance on implementing sprints or other processes (or general coaching), you can schedule a free session with me here.