Tag: kaizen

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.

Too busy to improve

I’m starting with an assumption: that we believe there is always the need for improvement (in what you produce and/or how you make it). If your product/team/system is perfect then you can stop reading now and go feed your unicorns instead. 😉

The next group I’ll invite to stop reading are those who believe it’s everyone else who needs to change but not themselves. I have worked for organisations where senior/middle managers want the coaches to “fix” the teams. Unfortunately, there can be no significant improvement until those people realise they’re not just part of the solution, there’s a good chance they’re actually part of the problem.

Hopefully, we are agreed on the need to continuously improve, and to be part of those changes. So how are you demonstrating that? Do you make sure there’s time for experiments or do you constantly push for more output? Do you encourage the team to discuss frustrations even when that might lead to questions about the organisation’s structure or decisions that have been made higher up the org chart? Do you help the team look deeply at themselves too, because effective retrospection and root cause analysis is not easy?

One unfortunate anti-pattern I’ve seen is “we’re too busy to improve”. This may be understandable for a week or two, but when this persists then it’s a red flag. I’ve encountered variations of “the Product team want us to focus solely on delivery”, or “leave the teams to get their work done”, or even “if it doesn’t help us get stuff done then we don’t have time to look at it”.

This is a very short-sighted approach; I’ve seen it paired with cancelling vacation or requiring overtime. The focus becomes the quantity of output, often at the expense of quality, sustainability, and the team’s health. Sadly the eventual outcome is often the realisation that what was produced wasn’t even all that important or urgent.

Returning to the presumed assumption that time spent on improvements will not contribute to helping the team deliver more, it’s important to ask why. If the time spent on retrospectives each sprint (commonly that’s 1 hour every 2 weeks) cannot be spared, then your plan is already incredibly fragile and very likely will fail – how will you cope if a team member is sick for a day, for example.

So rather than focus on the cost of improvement, think about the potential benefits. What if that one-hour retro resulted in an improvement that saves the team a few hours? What if the retro highlighted a concern about the quality or design of the work they’re producing? What if the conversation resulted in the discovery that a critical element had been skipped due to cutting corners because they are under pressure?

Saying “we’re too busy to improve” is a step back towards waterfall; it sends the message that “we know everything we need to know” and that nothing can be learned from the work the team are doing. More damagingly, if that is believed to be true when under pressure, when it’s finally lifted why would the team return to doing retrospectives and looking for improvements?