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.

Happy Birthday Agile

It’s twenty years since the Agile Manifesto was created in Snowbird, Utah. There’s obviously been lots of people posting about whether it’s still relevant, whether it should be revised, and so on, but I think it’s still important and applicable.

It starts with: “We are uncovering better ways of developing software by doing it and helping others do it.
It doesn’t claim to be definitive; “We are uncovering” means we still have room to learn and improve how we do this. There are many “flavours” of agile, including Heart of Agile and Modern Agile, and some organisations develop their own take on agile (but “hybrid” agile-waterfall monstrosities don’t count in my book).

The next few lines (i.e. the rest of the manifesto) seem to be problematic for some people because they don’t fully understand “we value the items on the left more” – the manifesto’s authors even spell it out by saying “while there is value in the items on the right” and yet some people still think “Agile means we don’t do documentation”.

The first of these, “we have come to value: Individuals and interactions over processes and tools” is one I’ve see many organisations fail to grasp. It’s a long-running joke in the community that “installing Jira” equals “adopting agile”. I’ll refrain from ranting about Jira because the point is that any tool is not the way to become agile – it’s about people. I remember another coach saying “If a company doesn’t understand that it’s all about people then they don’t deserve agile”! 🙂

The next line, “we have come to value: Working software over comprehensive documentation“, is the one I see people misunderstand most – I wonder if that’s because so many people hate writing documentation? If you think about the two extremes, neither is ideal: documentation without software is clearly not a useful product, but also software with no documentation is rarely desirable (a simple tool with no user interaction might just about be ok, but even then anyone trying to fix/enhance the code is likely to benefit from some docs). That’s why we value working software more than documentation but not instead of.

I think the third line is easier to appreciate if you’ve ever worked on a waterfall project where we’re expected to blindly follow the documented specifications and hit deadlines, even if it means delivering something we know to be wrong. By valuing “Customer collaboration over contract negotiation” it means we would rather work with our customer, e.g. show them demos (or better yet give them something they can use) and get feedback early and often. If you don’t work with your customer and respect them, then how can you expect to keep them as a customer? (Ignoring monopolies/cartels, obviously; add banks to the list of rants I’m avoiding in this post!)

The final line, “Responding to change over following a plan” is closely linked with the previous one – in an ever-changing environment like software development there is always going to be change, whether that’s feedback from the customer “course-correcting” the direction of the product, or how the team works together (e.g. coming out of a retrospective), or the tools/technology that we’re working with. To ignore those changes is to say that we can’t learn anything during a project; I can’t think of a single instance where that’s been true, even working on tightly constrained legislation/standards-based projects – there’s always something discovered along the way. However, just like documentation, that doesn’t mean we work without plans – we need to understand where we’re heading and how we think we can get there… but we also need to revise the plan when things change. We need a roadmap (i.e. a destination and options for getting there) rather than a single route set in stone … but that feels like a future post 🙂

Coaching backlog

One challenge as a coach is deciding where to spend your time – do I help team A or team B or split my time between them? If I had the capacity to give both the attention they need then it’s not a problem but of course there’s never enough time to go round. Like so many things, it comes down to prioritisation… but what goes in the backlog? Personally, I tend to think in terms of experiments, e.g. will smaller stories improve the team’s ability to respond to changes in direction?

(I should add that when I say “team” I’m actually thinking about the people in the dev team, the other people they work with, the stakeholders, and the system which encompasses them.)

But who creates the backlog items? Obviously, there are things which come up in conversations with the team members and stakeholders, but there’s also observations and comparisons between the current system and a potential “next level”. Now, we all know there aren’t actually “levels” but there are things we tend to observe in high performing teams compared to relatively new teams. I’m not going to touch on “assessments” here – I’ll save that for a future post.

In order to share this backlog with the coaching stakeholders (which includes the team) rather than a simple backlog of Stories, something like a POPCORN board can help support the conversations around which experiments to try and what the outcomes were. POPCORN is a backronym for: Problems & observations; Options; Possible experiments; Commitments; Ongoing; Review; Next – you can watch Claudio Perrone, aka Agile Sensei, present POPCORN at Agile Testing Days 2017.