Tag: growth

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.

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.