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.

It’s not all about delivery

As I wrote in an earlier post, The first of the Manifesto’s principles is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. It is our highest priority, but it’s not our only priority.

If we only focus on delivery, then we become a production line that does the same thing over and over again. That wouldn’t be so bad if what we did was the absolute best possible thing, but that’s not realistic – that’s why we have feedback loops and strive for continuous improvement. (Incidentally, even production lines aren’t focused solely on delivery!)

Not only do we need to collect feedback but we also need to be able to act on it, and to do that we must have room to make changes. If we are always rushing because of deadlines or other pressure, then we don’t have time to improve; in fact, we’re probably on a downward spiral which will result in frustration, mistakes, burnout and eventually people will quit. Warning signs of this slippery slope include perfunctory demos and sprint reviews (because there’s no time to improve the product), and ineffective or even skipped retrospectives (there’s no time to think about how to improve the way we work, but even if we did discuss it we can’t address the biggest problem which is lack of time so instead let’s spend that time cranking out more code).

But it’s not just time that’s needed – there must be room to grow, both personally and as a team. This is one of the biggest things a manager can do for a team – ensure that the team members are getting the training, mentoring, coaching and support they need. (If your organisation doesn’t have managers then hopefully there’s a similar role to support everyone’s development. If you don’t have managers because the Scrum Guide doesn’t mention them then consider that the Guide also doesn’t mention payroll but everyone still expects to get paid!)

A warning sign that I watch for is when someone (often the Product Owner) tells the team there’s no capacity in the next few sprints to tackle technical debt or any improvement experiments because “we’ve just got to get this feature out”. Unless there is an ironclad guarantee that the sprint(s) following the release will be focused on those postponed items, then I would suspect that the same message will surface again and again. When the sole focus becomes delivery I’ve seen teams resort to hiding work (tech debt “goes dark”, i.e. disappears from the kanban board) or a rigid division of time is introduced (20% of every sprint is withheld for technical tasks) – neither is healthy but they are understandable.

So how do we make room? A key step is for people to stop saying “deadline” when they mean “target date”. There are some instances where there really is a deadline (e.g. if legislation requires compliance starting on a particular day, then that’s probably a valid deadline) but more often when a team is told “the release deadline is June 30th” that’s actually a target. If the date can slip, then it’s not really a deadline. If the date is tied to someone’s bonus, it’s not really a deadline. Artificial deadlines cause unwarranted pressure. [This is a pet peeve of mine so I’ll write a separate post just focused on deadlines.]

My other recommendation is to improve how plans are created. (Even if your team has adopted #NoEstimates, there’s probably still someone in Sales who has to create a plan.) Even when the dev team is adept at relative sizing for stories, it’s not uncommon for people outside the team to estimate features in days or weeks and that is where the problem begins. Ideally, when someone asks how big a future feature is, the answer should be in terms of “yesterday’s weather”, e.g. “it feels like feature X that we did a couple of months ago” and then inspecting the data for feature X will provide some rough estimates.
The big assumption is that past conditions (when the team delivered X) will be similar when they work on the future feature… but if tackling tech debt, having effective retrospectives and running the associated experiments, and other “non-delivery” activities were postponed because of pressure to deliver feature X, then don’t be surprised when you encounter the same problem in your next delivery.

It’s not all about delivery; work at a sustainable pace; pay attention to all your feedback loops (and act on that feedback); don’t introduce unnecessary pressure (e.g. artificial deadlines); nurture your team members; improve your product. If you care about your people and your product, and I assume that you do, then ensure there’s space. Without space, the ability to deliver a quality product will suffer.

Scrum doesn’t work for us

Hearing a team say “Scrum doesn’t work for us” can trigger a negative reaction, based on an assumption that the team doesn’t understand Scrum or isn’t doing it right, but it could be a positive sign – maybe the team is growing and needs to move beyond “Scrum by the book”.

Scrum can be a good starting point because it provides structure and guidelines on how to “do” Agile – the Scrum Guide specifies roles, artifacts, and events. It specifies pillars (transparency, inspection, and adaptation) and values (commitment, focus, openness, respect, and courage), so it also tries to instil a mindset of “being” Agile. Scrum’s definition states “Scrum is simple” and “purposefully incomplete”; it is not intended as an endpoint but as a stepping stone on an Agile journey.

But rather than say “we’ve outgrown Scrum” and throw it away, this could be an opportunity for the team to inspect the way they work, consider which aspects they would like to change, and then run experiments to try to move towards where they want to be. That might sound like a retrospective, and that’s not an accident – effective retrospection is, I believe, the engine that powers change. If, for example, a team identifies the way that they collaborate during a sprint as something they could improve then they may decide to try pairing for the next couple of sprints. After those two sprints, they should ensure they discuss collaboration in their retro and whether pairing is helping – it could be they decide to extend the experiment, try something different, and adopt it permanently as part of how they work.

Another example could be to move towards kaizen (continuous improvement); maybe the team decide it’s working so well that they decide to drop scheduled retrospectives from their calendar. A purist might ask if you are still doing Scrum if you aren’t doing everything in the Scrum Guide; as a pragmatist, I would be pleased to see the team grow and wouldn’t care what they call it.