Delivering projects is an inherently stressful pastime, as anyone who has tried to manage one will attest to. Whether it is planning a wedding, moving house, developing a web platform, or even trying to get down to the supermarket for the weekend shop, all projects tend to induce some sort of anxiety. And that is because projects require a plan, they have a variety of requirements, some of which are unknown, and they need to be delivered on time. So bearing in mind projects are inherently stressful for those trying to manage them, imagine how stressful it is for those who have to deliver the products – especially when you’re trying to get them to tell you when it will be ready.
Skilled individuals, not Prophets
In the world of digital, our resources, who produce the products we deliver, are designers, developers and testers. It is sometimes easy to forget that they are there because of their special skills - writing code, producing exciting and engaging designs, or guaranteeing quality standards are met - and not in fact because they are experts in providing quotes. They have spent years honing their skills to be able to do what they do to an exceptional standard. What they haven’t spent years doing is analysing the time it takes and knowing every variable and every risk that exists in a scenario, so that they can provide an accurate assessment of the time it will take. They aren’t data analysts or consultants, they are practitioners of their discipline, focussed on delivering their skills in the best way possible.
So what do we do when we have recruited this elite team of specialists, this group of finely tuned artisans, experts in design, code and quality? We shove them in a room, bombard them with requirements and ask them to tell us how long each one will take to deliver. And then we look exasperated when they struggle, like a rabbit in the headlights of a rapidly approaching juggernaut, to make sense of it all. What we are doing, in effect, is asking the farmer to tell you exactly how long it will take for his crops to grow. He’ll be able to say it’ll be ready in the autumn, but he doesn’t know the weather, the exact soil condition, the pests that may occur. In short, he isn’t able to predict the future. And nor can our chaps either.
So at best they are guessing, based on similar experiences. But even when the task is the same on paper as another project they did at some point in the past, it isn’t exactly the same and they will have entirely different issues to overcome each time they undertake it. One of the principles of Agile is that it aims to reduce stress in the team, something that I think we can all get on board with, so it does seem incongruous that at the same time we subject these people to a session called Planning Poker.
Planning Poker is a session designed to allow the team to come to a consensus on the scale of a task. The principle is to try and divorce the concept of time from the scale of a task and therefore use an alternative scale to hours, for example dog sizes. Is the task a Chihuahua or a Rhodesian Ridgeback for instance? Principally you are comparing the current task to previous tasks to say whether it is bigger, smaller or the same. This is all well meaning, and in no small part quite entertaining, but it doesn’t actually deal with the issue of divorcing the time. Whether you ask the team to say it is a dog, a pint of beer, a length of spaghetti or any other arbitrary object, the thought process inevitably still comes back to “how fast can I do this?”. It is the only logical way to make sense of the request in the guise of being asked to give a scale. What it boils down to is that you are still putting them on the spot to commit to a scale. This is stressful for anyone. And it means we aren’t focussing on the actual matter in hand, the detail of what is required. Inevitably this means we compromise on quality. The quality of the process, the quality of the detail and the quality of the end work.
What is clear from the above is that the thought process is focussing more on time than it is on detail and complexity. Thinking about it as a dog rather than hours doesn’t change that, it just means the Product Owner needs to know the conversion rate of his Dachshund into hours of work.
The reality is we still have to plan the time usage of resources, no matter how we go about giving tasks a scale. We have to provide quotes to clients and plan work in to be delivered and without an idea of how long something will take we can’t do this. But accuracy is the key ingredient we are looking for. We want to know that what our resources tell us is converting accurately into a quote and a time, so that we don’t overspend and we don’t under deliver and miss deadlines. So how do we reduce, or dare I say it, remove, the stress of this process and increase the accuracy of our planning?
Focus on complexity, not scale
A realisation we’ve recently had at Siteset is that we do need to try and change the way people think. We need to move away from worrying about the time it will take and instead concentrate on the variables and complexities of a task. We have been guilty of using t-shirt sizes that equate into hours for our ratings. And whilst this has worked to an extent, it has often resulted in the same stresses meaning we under estimate and ultimately the team feeling like they’re constantly put on the spot and then when they’ve got it wrong that they have to take up the slack. So we decided to make a change.
We have scrapped the t-shirt size cards because we realised it was asking them to look at a ticket and then put a value on it, which is basically asking “how long will it take you?”. What we have done instead is introduce a three card system:
- Complexity Cards
- Working Method Cards
- Testing Overhead Cards
Our complexity cards ask them to decide how complicated a task is going to be, ranging from trivial to very complex. The working method cards ask them to select whether it is a task that an individual can do, or will need either pair or mob programming. And finally the testing cards ask whether testing setup is needed and whether the testing is straight forward or not. At no point in this process do we expose the team to the actual scale this equates to, but instead have an algorithm that takes all of the variables into account and then produces an amount of hours and an overall scale for the task (our original t-shirt size).
Changing the process produced an immediate affect. The planning sessions, which had become a bit of a ball and chain around the soul, immediately became more dynamic and more engaged. The algorithm approach also means that we can tweak the values based on our learnings over time, without affecting the scale we are using. This is much more flexible. In short, doing this has moved the team away from focussing on the stressful question of “how long will this take you?” and moved them to think about the detail. The knee jerk thought process has now become an involved and methodical one which often uncovers more of the potential issues.
Our farmers still can’t predict the weather weeks in advance, but they are now looking at the horizon to see what colour the clouds are that are coming, rather than just sticking out a hand to see if it is currently raining or not.
Had a year really gone by since my maiden experience of Agile on the Beach? 52 weeks since I was ...Read More