We create value in software development by building the right thing, building it well, at the right time.

The “right thing” implies identifying the most valuable work items, “building it well” covers the quality of what we produce, and “the right time” means getting it in the hands of our customer at the right time.

We need to wrestle this equation like a skipper wrestles the boat in turbulent waters. As the waves batter our delivery boat, the line between knowing what to work on next, balancing quality and knowing when to start becomes increasingly indistinguishable.

As delivery leads, we…

“We are unique. We are doing something special. In our case, all that Agile stuff is not applicable, and it goes out of the window.”

And this is how it begins — an endless energy-sapping battle of whether Agile applies to us or not, to what is Agile.

How can we move away from these arguments to those that matter? To use our finite energy to unlock the real value for our customers?

There is an XP programming practice called incremental design — a practice that encourages investment in the design of the system everyday.

While this principle is referring…

Many people around the world have been forced by current circumstances to work from home, and they find themselves needing to adapt very quickly.

Given this swift and abrupt transition, it is reasonable than the new way of working can be unsettling, and potentially even less productive for a while.

As a practitioner, do you find yourself spending most of your day in back-to-back in video conferences? Do you feel overwhelmed to stay on top of all the emails and the proliferation of various messaging platforms, perhaps concerned about getting things done? …

Something is not right. We ought to do better, I know that. But how? I think I need to consult an expert.

This is a common thought process for someone who cares and wants to improve the working practices of an organisation. It is very tempting to solely rely on experts to fix our troubles, but the problem is that in life there are no silver bullets. While experts can help, there is always a risk that they will match their most recent experiences with the new situation, and will apply previous solutions to the new context. …

Have you ever worked in a project where tracking and reporting of work was always seen as a chore, something that wasn’t considered useful? As time goes on reporting slowly deteriorates. Or maybe it was never good. Then, all of a sudden, the lack of visibility makes the clients nervous and feeling out of control.

You know that it is useful, but you seem to be in minority. So, how do you motivate teams in these situations to take this topic seriously?

Here is my take on the problem …

Avoid at any cost the ‘stick’ approach by telling teams…

No matter how much I wanted to avoid the topic of delivery timelines, it was always coming back – ‘how much can we build, when will it be done?’

These questions are significantly harder to answer when multiple teams are working together on the same problem — for instance they all work against one roadmap to build a product. Estimations are inherently difficult [1] and as soon as you go beyond a handful of deliverables, knowing what can be delivered it’s tricky.

Faced with this problem on one of the projects I was working on, my initial instinct was to…

Introduction

‘When will it be done?’ is one of the most common and difficult questions to answer in software development.

Estimating in software is traditionally difficult, inaccurate most of the time, with project teams spending a significant amount of time on the process.

There are a number of contributing factors to this. Part of it is that software development is a design activity, and thus hard to plan and estimate. Software is done with people, and it depends which individual people are involved. Individuals are hard to predict and quantify and humans in general are inherently bad at predictions [1]. …

You’ve got a project to deliver. You’ve got a neat plan. You expect that the team will deliver the scope as planned.

The work starts. You start with two components, A depending on B, each backed by a delivery team. You issue a plan showing delivery of A and B. Soon after the work starts, you discover that B needs a change of an existing component C not owned by your teams. No panic, you just need to find a team to make the changes for C. The changes are not big, but the team responsible for delivering C is…