BIDE your time with Agile

In February 2001, seventeen software developers (all male) met at a ski resort in Utah to discuss new ways of managing software development that were less cumbersome and more effective. The outcome was the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Naming themselves the Agile Alliance, the writers published their statement online and encouraged others to sign, adding if they wished a message of support. Signing closed in 2016, by which time more than twenty thousand people had added their names to the list. I heard about it and signed in April 2004 - feeling, like many others, that the Agile manifesto summed up many of the things I was most passionate about:

My whole working life has been underpinned by an interest in tools and techniques to facilitate and support human collaboration - the invisible, untidy, innovative work that in the end is responsible for delivering a project, a product, a business, ... until all software is written by machines, we need Agile methods. And probably even then.

Over two decades later, Agile methods have spread far beyond software. However, there are still many issues with using them in practice. One issue is how the Agile focus on constantly delivering valuable output creates tension with attempts at long-term strategic planning. Another issue, which I'll discuss here, is how to manage people's time, even over the short-term. Agile practitioners view traditional delivery planning (size tasks for effort then match to available resources to set expected deadlines) as neither efficient nor effective. As an alternative, Agile teams encourage their members to size work using Story Points - a concept that many people struggle with.

The principle behind Story Points is to quantify a work item in terms of the output it represents. You do not estimate what is required to deliver it, but rather how much its completion will contribute to overall progress. You can then measure the team's delivery of Story Points to track what in Agile practice is called velocity - a term chosen carefully. Velocity measures the distance covered over a period of time, not the effort required to do so - km or miles, not calories or fuel. For a team member to estimate the Story Points for a work item, they need to think about the value it will deliver, a practice that helps ensure people focus on what is truly important, rather than on bells and whistles.

Each team, and each team member, will assign Story Points to work items in a different way, and that's fine. What you are after is not an objective measure, but a subjective one. The two aims of a team are to increase velocity and to make velocity more constant, with less fits and starts. Then they will not only become more productive but also be better able to manage their work.

However, many people find it hard not to equate Story Points with effort - even if they know from experience that effort is typically unrelated to value delivered. Most of us are occasionally lucky or smart enough to complete something that seemed huge and complex in a few hours. Conversely, we've all hit snags and spent a week on something that is essential but only a very small part of the overall picture. Either way, the value of your work remained the same. I remember some of the reasons why Story Points do not equate to effort using the acronym BIDE (as in bide your time):

• Bugs. You may start something only to realise that you should have done more research. You may nearly finish it, only to come across something that puts you almost back to square one. Allowing a standard contingency percentage can help but more often ends up being wild of the mark.

• Interruptions. Whether you work on site or at home, people will tap you on the shoulder. This could be physically or via messaging. Interruptions can come from anywhere without warning - an unexpected work item, an illness in the family, sudden storm damage to your house, your dog eating something it shouldn't and needing a vet trip, you name it.

• Dependencies. You can plan for dependencies but ultimately they represent an unknowable risk.

• Exhaustion. No-one works at the same rate every hour of every day of every month of every year. In between the times when you perform at your best, you need to take it a bit easier or will eventually burn out. What's more, it can be hard to know when you'll have a good day and when you'll be too tired or stressed to deliver as you might like.

This drives some people up the wall. A key part of the Agile process is to estimate, at the start of each Sprint, which work items you will complete during it. How can you do this if Story Points do not represent effort? The only way is to remember the Agile principle of fixing Time (and Cost) and allowing Performance to vary.

In other words, look at your highest priority work items and think about how to divide up the next Sprint into corresponding timeboxes. Suppose the Sprint is 2 weeks long. Roughly, does it seem reasonable to spend the first week on the top item, then 2 days on each of the next two items? If so, set your Sprint Goals accordingly - and stick to the plan. As you approach the end of each timebox, start winding up the corresponding task, leaving undone anything you won't have time to complete.

When you come to planning the next Sprint, you may feel a strong desire to add the work you didn't have time for to the Backlog as new Stories or Tasks - but take great care about accumulating technical debt! That way madness lies. To be Agile is to focus not on perfecting what you did before, but rather on what great new things you could do next. Instead of filling a gap in the configuration of an old tool, is there a new tool you could replace it with, in which the gap is filled out of the box? Instead of preparing a contingency for every possible edge case, is there a new opportunity that dwarfs the importance of all such edge cases?

Sometimes you will feel that a technical debt is truly important - for example, it may represent a security or safety issue. Even then, sanity check it with colleagues before adding it to the backlog, which all too often becomes the millstone around a team's neck. There is always more than one approach to a problem, and often your colleagues will reassure you that the issue isn't as important as it seems (or important at all). This way you have done your duty by raising it, covered your back, and with a clear conscience can live the Agile dream - every Sprint, move on to new and ever more exciting pastures.