One of the challenges I often hear from developers is about focus – there are good reasons to avoid multitasking (a big one being that people can’t multitask – it’s actually time-slicing and incredibly inefficient) but at the other extreme working on a single problem for a whole day is also ineffective, so what’s the ideal amount of time? [Drum roll] It depends! 😉

My personal preference is based on the Pomodoro technique – I like 25 minute timeboxes of focused work interspersed with 5 minute breaks. It fits well with breaking work into small chunks, which means I need to understand the problem I’m tackling and think about a path towards the goal. The other benefit I find is that it’s a good reminder to switch between sitting and standing at my adjustable desk.

There’s a perception that longer timeboxes equate to more focus, but people’s concentration tends to wane after about 45 minutes hence the “ideal” could be using an approach like Pomodoro and allocating multiple timeboxes to the same problem: 25 minutes working on a problem, a 5 minute break, and then another 25 minute timebox will (for most people) be more effective than 45 minutes without a break. The focus-and-break cycle should be sustainable throughout the day, so every so often the technique recommends a longer break; it’s also good to give your eyes (as well as your brain) a break, and even do some stretches.

But, of course, it’s not that simple! If one person is “in the zone” and focused solely on their work for an entire day then they haven’t been collaborating with their teammates or getting feedback from their customer. That may feel good for the developer but agile is a team sport – “the needs of the many outweigh the needs of the few”. The sprint commitment is made by the whole team. Having only one team member understand a problem or the design of a solution is fragile – if that person is unavailable (e.g. on vacation for two weeks) then the rest of the team is blocked from making progress.

The other reason to break that focus into smaller chunks is to demonstrate the work in progress and seek feedback. If you only get feedback every other day, then the potential exists for a lot of rework and wasted effort – the longer the interval, the bigger the risk.

One additional thing to consider: it is important to look ahead, not just focus on the work at hand, so there is a need to fit refinement or replenishment into the schedule, as well as the daily stand up or other team coordination meetings. Without looking ahead all that focused effort could be for nothing if it doesn’t fit into the larger vision.

Delivering Value

It’s fundamental to Agile! The first of the Manifesto’s principles is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”; Modern Agile has four principles, which includes “Deliver Value Continuously”; Heart of Agile says “Deliver small probes initially to learn how the world really works. Expand deliveries as you learn to predict and influence outcomes”.

So who defines what’s valuable? I expect it would usually be your customer (conveyed by the Product Owner) but identifying them can be tricky. Not everything in the product backlog is destined for an end-user; you could be building internal tools (then your customer could be other dev teams) or for yourself. The key thing is identifying what “value” means – this helps the team understand why the work is important as well as where they’re heading. User stories should focus on the “why”, the goals and benefits.

Once the goals are clear, how does a team deliver value? Incrementally, getting frequent feedback to allow them to make adjustments towards meeting the customers’ needs. I like Heart of Agile’s additional mention of “small probes” – taking small steps at first, as you discover more about the goals, technology, etc. As the team become more confident they may want to take larger steps but, in my experience, even when you’re “100% sure” what to build next there’s always a surprise in store. It’s like gambling: don’t risk more than you’re willing to lose – don’t build more than you’re willing to throw away once you get feedback.

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]

Priorities Change

One of the Product Owner’s key responsibilities is to ensure the backlog (well, the top of it, at least) reflects the stakeholders’ priorities. Of course, the certainty of those priorities decreases the further out you try to look: we ought to be pretty confident in the priorities for the next couple of weeks, but less so for a couple of months away, and if we’re thinking 6 months ahead then it’s quite a low certainty. (Your timescales may be different but the “funnel” model should still be applicable.)

The reason certainty decreases the further into the future you try to predict is that things change! Hopefully, you’re learning more about your customers over time, but also their needs change. There are also changes in technology which mean something you couldn’t build last year is now possible, or maybe the costs have dropped so now it’s worthwhile.

Like everything we do in Agile, it’s about feedback: we think the customer needs X so let’s build just enough so that we can test the market, i.e. a Minimal Viable Product. Based on the learning from that we should adjust the backlog, so putting too much effort into the details of a plan that’s likely to change is waste. No matter how much you believe you know what your customers need and spend time drawing up a 12-month plan, if your plan doesn’t change then either (a) you’re a genius, (b) you’re really lucky and should play the lottery, or (c) you’re not listening to your customers.

Even in a tightly regulated market, things change – if your product is constrained by legislation, there can be changes resulting from interpretations of the law or even changes in the law itself. If your plan is unable to reflect those changes in a timely manner, don’t be surprised when someone beats you to the release of a “fully compliant” version.

The key is to have a plan which gives enough context for the current/imminent work but which is flexible enough to react to changing information, as well as to have people who understand that a plan could (and should) change when circumstances change.

Maybe that’s the most important piece: having people who ask why when a plan doesn’t change?