When I say resources, I mean resources

It shouldn’t need to be said, but unfortunately there are still people who refer to others (usually subordinate staff) as resources. As we become more aware of potentially offensive or harmful language and make efforts to change the words we use, I hope resources will appear on the list of inappropriate terms.

I still wear my #PeopleWorkHere T-shirt from This Agile Life as a visual reminder.

I think the second image comes from Mike Cohn (Mountain Goat Software) but I can’t find it.

But on to the real topic: where to find reliable agile-related information? The benefit of the internet is having access to so many resources, but the downside is that anyone can post their (mis)understanding – it’s important to check that the author has relevant, practical experience.

Personally, I find podcasts a great way to learn about new techniques etc. I tend to play them at 1.25x (or sometimes 1.5x) speed because I follow a lot of podcasts (across many topics) and at that speed I can just about keep up with the influx of new episodes 🙂

Unfortunately some of my favourites haven’t released anything in a year or more, so my currently-active favs are:

Similarly, I have a backlog of webinars and books. I don’t follow any agile-related YouTube channels; I tend to come across videos via email (mailing lists), websites, slack, and the infamous YouTube rabbit hole, and then I add them to my bookmarks to watch later. If there are some good channels that you would recommend, please leave a comment.

Update: I checked and actually I do subscribe to a few YT feeds:

OK, that’s a longer list than I expected!

Ultimately, I think it’s about finding a format (or formats) that works for you and then identify some reliable authors. But it’s not just about absorbing information – it’s useful to discuss concepts and challenges, and (as the saying goes) the best way to understand a topic is to explain it to someone else. Meetup groups (albeit online at the moment) and twitter (I have an agile list of people I follow) are good, but the one I find most useful is my team’s coaching circle: a weekly opportunity for us to discuss our challenges, discoveries, experiments, and questions. Rather than squeeze this in at the end of a long post, I’ll write a separate entry about how this format works and the type of things we discuss.

Developer or Engineer

When I graduated (many years ago!) my first job was as a Developer. I was one of about 90 developers on a multi-year project (I think it was in its third year when I joined) and my role required me to churn out code according to the detailed design specification. Follow the design, turn it into C code, make sure it compiled and passed some basic tests then throw it over the wall to the QA team. You won’t be surprised to hear that the project was not a success. In fact, when the company was sold about four years later the new owners discovered two other very similar projects had been underway for about the same time, and none were close to done.

Rather than point out how things could have been far better if they had used an Agile approach, I want to explore how the role of the Developer has changed. Even though we may still use the term these days, the expectations of a Developer have grown significantly. Writing code is just part of the job; as a Software Engineer, the expectation is no longer that of an individual following a design doc and converting it into code then handing it off to the next group in the chain. I’ve seen many argue (and I would agree) that coding is the least challenging part because it’s often what comes naturally as well as being the focus of most training.

Coding is still important, of course, but it’s not where most Engineers need help. Engineers are expected to participate right across the software development lifecycle. They need to be able to talk to their customer and understand the business needs; this used to be the Business Analysts’ role, who would spend a long time learning the domain’s terminology and nuances. They need to take that understanding and merge it with their knowledge of the system; this may require thinking like an Architect, to see not only how to get from where we are to what’s needed to address this particular problem but also to consider how that could impact aspects of the wider system, and even whether that direction is in line with the organisation’s overall technical strategy.

Now they need to implement that design, ideally writing tests first but if not then at least developing tests whilst creating the code. Producing small, testable, incremental steps towards solving the problem; don’t forget to check in with your customer to demonstrate the work in progress and get feedback as often as possible. With the move to DevOps, it’s now also the Engineer’s responsibility to push that code into Production and monitor it so that any adverse events are handled as quickly as possible so as to minimise business impact.

There are probably a lot of things I’ve not included (I know I didn’t mention documentation, UI/UX design, or the many flavours of testing) but my point is that a Developer used to be able to focus on a small step in that process and become an expert in particular languages or techniques; now we expect Software Engineers to be highly competent across a diverse range of skills.

One of the benefits of working in teams is that an individual doesn’t have to be an expert in all those skills – the cross-functional team should contain Engineers with a variety of backgrounds so that the sum of their knowledge covers all the needed areas; diversity of experience, knowledge and interests. We don’t want a team made up of a Business Analyst, an Architect, some Developers, and a QA tester or two – that would just be a mini-waterfall team and would lead to the same flawed processes that I encountered way back when I was starting out.

What we want is a team with at least someone with strong BA skills, someone with design/architecture experiences, and most if not all the team to have an appreciation for testing. And then we want the team to share that knowledge; it’s unlikely all the team members will become experts in all the areas, but they should have enough knowledge so that they can continue to function if a particular domain expert is away for a couple of weeks. We want the team to learn from each other, but that takes time and practice so we should be building that into the expectations of the team, and that means including it when the team is asked to estimate work.

If we expect a team to strive for continuous improvement (in their knowledge, practices, and all aspects of their work) then we need to ensure there’s support to do that. If we constantly focus on delivery or tell a team that they have to hit a deadline, then learning & growth are among the first things that are sacrificed. If leadership doesn’t lead by example and show that they value kaizen and education, then don’t be surprised when the team stops making time to grow.

The role of a software engineer is broad and complex; we need to ensure that we nurture that growth or we’ll revert to having silos of specialists who don’t collaborate, and we’ll wonder why we’re producing poor quality solutions.

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.