Too Many Options

Teams collaborate to create high-quality products, and in order to collaborate they need many discussions… but how much discussion is too much?

Why do teams need to have discussions at all? Wouldn’t it be quicker if someone created a series of tasks and then the team just implement them? Well, it may be quicker to release something if everyone just did as they were told, but there are so many problems with this approach that I don’t have time to list them all! Some of the biggest issues are that it’s a single person’s understanding of the problem and the rest of the team probably don’t understand what they’re doing or why, which leads to a sub-optimal solution which the team can’t support without that one person’s involvement… but the “hero” of that project has no doubt been moved on to something new, set to repeat the “success” of that rapid release.

Instead of relying on a single person (who I’m trying to refrain from calling a single point of failure) Agile teams collaborate on all aspects of their work, sharing their knowledge. User stories focus on the Who, What and Why, leaving the team to work out How. The Product Owner sets the scene, explaining the business aspects; the development team should seek to understand their customer, how this story will impact them and what benefits it is expected to deliver. This discussion may take a while, but it’s usually the next step that takes the most time: deciding how to produce that deliverable.

Before starting a sprint, the dev team need to have a reasonable idea of what they will deliver. They need to have enough understanding of their approach that they can have discussions with the Product Owner about the size and scope of the work, i.e. the Negotiable part of INVEST. Teams can go overboard and spend too much time upfront; there will always be surprises during a sprint, so it’s better to limit the pre-work and put that effort into the sprint work. But if teams go too far the other way and do no preparation, then they miss the opportunity to discuss how much is “just enough” to meet the customers’ needs.

What happens if the team cannot agree on how to approach a story? The team could keep discussing their options ad infinitum, often called analysis paralysis, but at some point the team have to recognise that they are not converging so continuing to talk will not help. They could invite others to join the discussion, but that can lead to problems around impartiality; it also doesn’t help the team learn how to react the next time they reach an impasse. One helpful step could be for the team to conduct a spike, building a small proof of concept so they could compare a key difference. Perhaps a few spikes are needed in order to extract the best pieces of each approach – it’s rarely as simple as A or B, and more often is a hybrid.

One last thought: don’t just discuss ideas – draw them! Not everyone can draw (I’m terrible!) but a tool like mural.co makes it easy to use their built-in images or import graphics found online, so there’s no excuse to skip this important step. It’s too easy for team members to think they all agree on the approach, but making it visible will help bring any misunderstandings to light.

Healthy Environments

If you want to grow, whether as a team or individually, you need a healthy environment that allows you to thrive. There are so many things that could contribute to a healthy environment, so I am going to pick just a few as examples. (I’ll skip development environments other than to say I use vi when I write code or websites.)

The most tangible components include your desk, or wherever you work most days. I was lucky enough to have my study set up well before we had to work from home due to COVID. An adjustable sit-stand desk and two large monitors connected to a Mac mini meant my transition to long-term wfh was fairly easy. I had recently upgraded our home wifi and already had pretty much the fastest available internet connection. My company generously gave everyone a budget to upgrade their home office, so I took the chance to buy a chair that I’d wanted for a long time. I’ve made a few small tweaks over the year or so of wfh, but you can find many of the main items on my kit page.

The next area that people tend to think about when setting up a healthy environment is related to ergonomics. Big monitors are great but if you don’t set them up at the correct height then you’re going to strain your neck. Stare at them without a break and you’ll strain your eyes. Sitting all day (even on my nice new chair) can cause other health problems. It’s important to have a comfortable place to work, so it may require a few adjustments before you find what works for you.

The big trick I find that helps me is to move often, whether that’s switching between sitting and standing, or walking away from the desk for a short break. I already used the Pomodoro Technique to help with focusing on tasks, but now I have incorporated reminders to move more.

Part of the impetus to write this post is the (literal) pain in my neck – I know I need to stretch and exercise more, and I should probably put some small blocks of time in my calendar to remind me to do that each day. Thanks to Matt for recommending another stretch that I’ll be incorporating.

So far it’s all been about the physical environment, but it’s also important to think about mental health. I am very quickly going to be out of my depth on this topic, so all I’ll say is it’s really important for everyone to pay attention to their own mental health and to be supportive of those around you. Many companies are providing additional mental health support because the COVID restrictions and extended isolation many people are experiencing are causing additional strain. Here are some resources:

Like so much of what we observe and how we understand things operate in agile organisations and in the world in general, there are many interrelated factors and that’s why we should consider the system, recognising that changing one element can have an impact on others. It’s important to acknowledge that there are many components of a healthy environment and it takes effort to maintain them; ignoring them can have dire consequences. This can be daunting and that’s why it’s important to ask for help – no-one is an expert in all aspects so we should not be afraid to seek assistance, and hopefully we can support each other.

Forecasting Using Yesterday’s Weather

When we talk about “forecasting using yesterday’s weather”, we mean that the most reliable prediction comes from using recent data, i.e. if you want to know how much a team can complete next sprint, look at how much they completed in the past few sprints.

The recent weather in Toronto reminded me of a discussion I had with a Product Owner: “how can we use yesterday’s weather when what happened was unexpected and unlikely to happen again?” In the past week, the temperature here peaked at 31°C and three days later we had hail and snow. If we forecast next week’s weather using last week’s data, then should we expect to see both extremes again?

Let’s review the PO’s question in this context: was last week’s high and low weather unexpected? Well, the short-term forecasts warned that both were coming. But even if one or both were unexpected, would it matter? It’s not like we expect weather forecasts to be 100% reliable – that would be unrealistic.

Are those conditions unlikely to happen again? Well, that depends on your definition of “likely”. Will it definitely, 100% guaranteed, without fail, happen tomorrow – probably not. Will it happen again at some point in the future – probably. I’m still not willing to say yes or no because that’s not how forecasts work! Will we see both 30°C heat and snow tomorrow? I’m going to say that’s very unlikely, but I won’t go as far as 100% certainly no.

So if we can’t give the PO an ironclad guarantee, why should we use “yesterday’s weather” when forecasting? Well, we could revert to asking the team for their estimates (which is usually an “educated guess” or just “gut feel”) and then tell them they have to meet the date which they supplied … but that’s not going to be a reliable forecast, and is likely to result in inflated estimates if the team feel they are being misused.

If we have to use forecasts, then using representative data is the best basis. We also need to understand probability, that asking for high confidence in an estimate means you’ll get a very conservative forecast. We also need to understand that the further ahead we try to forecast the more likely we are to be wrong; the best time to forecast the weather for 3pm tomorrow is at 2:59pm tomorrow.

But most of all, we need to understand that forecasts are a guess – if we do it right it’s the most reliable prediction that we can make, but it’s still a guess – so don’t gamble more than you’re willing to lose and be prepared to adapt when reality takes an unexpected turn.

Moving the sprint end date

Most of Canada has May 24th off work – Quebec calls it “National Patriotes Day” but everyone else knows it as Victoria Day. But what do you do if it falls during your sprint? I’ve heard some teams move the sprint end date to compensate, so their sprint is still the same number of working days. (I’ll use 2-week sprints for simplicity but YMMV – I’ve worked with teams using 1-week, 3-week or 4-week sprints, but I’ve never seen a non-integer week duration; have you?)

I can understand the thinking behind moving the sprint end date because that gives them the same capacity as other sprints, but I think it’s a slippery slope: would you move the sprint end if some of the team are on vacation for a week? What if the company introduces a weekly all-hands meeting that consumes 90 minutes of everyone’s time? Do you move the sprint review and retrospective by the same amount?

The intent behind setting a regular cadence for your scrum events is so that everyone knows when they happen, and it simplifies meeting scheduling (set a recurring appointment and let it run). Often key stakeholders have busy schedules, so knowing the sprint review will always happen at the same time makes it easier for them to move meetings around it. (I would argue that your stakeholders’ willingness to prioritise your sprint review over other activities is a reflection of the value/importance of the work you’re doing.)

A regular cadence does not mean that your sprints will always have the same capacity – today’s stat day (aka Bank Holiday in the UK) means a reduction of 10% of the sprint… or more if some of the team took Friday off to make a 4-day weekend. Hopefully, the team thought about this when they planned the sprint and adjusted accordingly. Some teams I’ve worked with use a simple spreadsheet as a reminder to check each team members’ availability – maybe one person is on vacation for a week and another is on a course for 3 days.
I stop short of then calculating what percentage of the team is available and applying that to their velocity – this isn’t a precise science, just an aide-memoire to get them to think before they plan. If the team still relies on one person for a particular skill (e.g. database design) and they’re away then maybe the team needs to rethink which stories they can complete… and hopefully that’s also the trigger for them to work out how to share that skill so they don’t hit the same problem again.

An extreme case usually happens around the end of the year: a combination of holidays, stat days, and using up personal vacation time can mean a 2-week sprint has a tiny fraction of the normal capacity. I’ve seen teams make an exception and have a one-off extended sprint, spanning three or maybe even four weeks. I’ve seen teams just stick to their cadence and plan on completing far fewer stories. Recently I saw some teams try an interesting experiment where they abandoned sprints and teams for those weeks – instead, they took the opportunity to work on their tech debt backlog and pair/mob with people they don’t usually work with. There’s no “right” way to handle the unusual circumstances but I would recommend resuming the regular cadence as soon as possible.