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.

Inspiration

I’m suffering from blogger’s block this weekend – I can’t think of a topic for a new post. I’ve jotted down lots of small things but nothing that I could write more than a paragraph on. But if I dig a bit deeper, I don’t think the topics are the problem – I just can’t conjure up enough excitement to give any of them enough attention. It’s a good thing I’m not getting paid to update this blog – a job comes with expectations and timelines, and trying to be creative under pressure is just not conducive to producing something worthwhile.

So how do developers cope when faced with a deadline? I remember when I was a developer that I often needed to leave a problem overnight before I could start to find potential solutions. But that was back in the bad old days of waterfall or plan-driven development – someone sets a deadline (usually an artificial one) and then we had to meet it.

How is an agile approach better? Here are a few things which spring to mind:

Deadlines are rare, but when there really is a deadline then the scope is variable. It ought to be obvious but I’ll spell it out because this should have been true in waterfall too but rarely was – if you fix all three sides of the iron triangle (time, cost & scope) then the only variable left is quality. Time is fixed because of the deadline; cost is the equivalent to the number of people working on it; so if you don’t allow scope to change then you’re basically forcing developers to cut corners. [I’m ignoring the argument for adding more people when the deadline looms – Fred Brooks covered this many years ago.]

Rather than adding people when it’s too late, why not start with two (or more) people working together from the beginning? Most companies require code changes be reviewed because they know having a second person look at a problem helps improve the quality … but collaborating on the design (when you’re tackling the problem) rather than reviewing the code (when you’ve picked a solution and gone down that route) results in an even better outcome. Having someone to discuss ideas with is so valuable that solo developers often use “rubber ducking” (yes, talking to a rubber duck!) as a way to clarify their thinking.

I find visualisation to be incredibly useful, for myself and when I’m sharing a concept with someone I’m coaching. When a team is discussing their confidence in meeting their sprint commitment, I find a burndown chart can challenge the overly-optimistic (“We’ll get it all done on the last day”) and lead to conversations with the product owner about relative priorities, expectations, etc. When discussing a new feature and how it will benefit the end-users, sketching the user interface may help build a common understanding, and story mapping can build empathy with the customer.

Frequent feedback can help too. Sometimes the enormity of a problem can be daunting, so break it down into more manageable pieces and take smaller steps towards the goal. Getting feedback on a small part of the challenge can be stimulating and provide inspiration for the next steps.

Please leave a comment: how do you cope when you hit a creative block?

Big changes, little changes

Some recent conversations have included questions around whether small changes or large changes are “better”. Unsurprisingly my answer was “it depends” 🙂

Even though our goal might be to achieve a big change, I would recommend making a series of small changes to get there because we might learn all sorts of things along the way, including whether we’re actually going in the desired direction (it’s possible our small change has taken us down a side road) and whether the goal is still the goal.

OK, but what kind of changes does this apply to? All, I think. For example, if the aim is to change the users’ experience by adding a new feature (that sounds like a big change) we would usually break it down into epics and stories, and maybe think about multiple releases … but we probably want to start with some experiments to see if we’re building something the users want, i.e. get feedback early. So the large change is broken into smaller changes (releases, epics) and then into even smaller changes (stories, experiments).

But how does the team learn to do this decomposition? Well, learning a new skill can be a big change, so let’s break it down into small changes too. There are different techniques, so pick one, learn it (e.g. read about it, watch a video) and practice – ideally this includes getting feedback from someone with experience of the technique.

This principle can also be applied to coding: small, frequent check-ins make it easier to spot problems – when a test fails you’re only looking through a few lines of code, not pages and pages. It also reduces the chance of merge conflicts because there’s less time between pull and commit, which means a lower probability of someone else changing the file you’re working on.

So, back to the original question: are small changes or large changes are “better”? Well, I think the answer is small changes are what enable you to make large changes, so it depends on whether you’re looking at the end goal or how you’re going to achieve it.

[Here’s the video of the domino chain reaction]