Based on my previous post on waiting and having business value items in the inventory of unfinished work for a long time due to juggling to other work, a colleague in twitter left me thinking about batch sizes.
He pointed out that with a small batch size, the wait time would be shorter. It's a great observation, but also in my experience, one of the most misunderstood principles in practice.
What is a small batch? I would think that is the smallest possible value you can add, for now, into the software. A batch is not a task. It's not that you've done "design" for something, but you need to go through all the layers to actually have the resulting value in production. Small batches are the heart of incremental development and delivery, and from a perspective of testing, I would claim I've been getting better to help my teams find the smallest possible things we could add.
The challenges with small batches tend to come with the tasks some people refuse to acknowledge. Like testing. If there's a really small change, adding six lines of code, it shouldn't take long to get that tested, right? Unfortunately, quite often the view into the system as delivering value connected with all kinds of things means that the very small change isn't a small one to test. And in particular, it isn't a small one to fix, as one (or more) of the connections were completely dismissed in the implementation. There's a very relevant, common use case that just wasn't in the focus of the change now.
So, small batches to some may be bigger to some others. And these surprises in how they are sized up are causing the waiting problems, as one has already "moved on", when more work on the same small thing arrives. The developer never committed to complete the value, just his idea of what tasks would be needed to deliver the value. And he is mentally engaged on the other tasks already when he is told, with examples, that it just isn't done yet. The message is not welcome, leading to a wait time.
This all is a vicious cycle. It eats away morale of us all. The tester, the developer, the manager. None of us is happy. So how we don't get it changed is a mystery to me.
There culture includes a "need for speed". Doing things continuously, incrementally fast. Just add more. Change it. And don't break it while changing. There's no test automation to support this. The building block of speed is the developer, who is pushed for finding a minimal solution that could be delivered quickly. The ideas of someone testing are new and are mostly making things worse. The time was already up by time of delivery, and now the poor developer has fixes to create, while feeling the pressure of the next quick feature is the queue. And often not just the external pressure but also internal - the next feature is more fun that fixing the old one.
Let me look at a small batch from one more angle. A really small batch without big testing implications that would look like an hour of work - it takes three days. Or in other words, a work week fits just two of those types of issues. When a developer is pressured with time, they learn to protect their other interests. The motivation is low as you're all alone with your assigned task, and you might not have the skills to come up with a solution. The first day goes into just procrastinating with the idea of having to do this. Google a little, read whatever you find, talk to your colleagues. Not directly on the matter of course, otherwise they might say that you're not good enough. The second day you try out some of the stuff and none works. On third day you ask directly someone who knows and can complete the task in an hour. And after the other developer did the actual bit, you spend time testing, checking and finalizing, as your name will still go on the fix.
I believe that while the idea of small batches is great, the relevant bit here is to do something about developer happiness, motivation and skills. There's a reason for any of us rather spending time procrastinating than working efficiently towards delivering the value. The pairing and other changes I suggest threatens the hidden self-development time. It threatens the permission to work remotely and not talk to your team mates for days. But it also holds a lot of potential to make us happier, all of us in the team.
How many "small batches" does your work week fit? Doesn't the whole concept of small batches make you feel bad about not completing so many of them in your week? I love the idea for trying to split things rationally from a value perspective, but I hate the work monitoring implications.
Not all batches and skills needed in them are equal. Not all days for a professional are equal. I'm great at procrastinating, letting my mind wander and building connections that wouldn't be immediately relevant for the task at hand. But the stuff I'm learning and realizing while at it, makes a big difference in the end result. But I also finish the work. Sometimes when I was supposed to. Sometimes early, sometimes later. Motivation and feeling the purpose make a big difference on whether a small batch is small in actual calendar time.
He pointed out that with a small batch size, the wait time would be shorter. It's a great observation, but also in my experience, one of the most misunderstood principles in practice.
What is a small batch? I would think that is the smallest possible value you can add, for now, into the software. A batch is not a task. It's not that you've done "design" for something, but you need to go through all the layers to actually have the resulting value in production. Small batches are the heart of incremental development and delivery, and from a perspective of testing, I would claim I've been getting better to help my teams find the smallest possible things we could add.
The challenges with small batches tend to come with the tasks some people refuse to acknowledge. Like testing. If there's a really small change, adding six lines of code, it shouldn't take long to get that tested, right? Unfortunately, quite often the view into the system as delivering value connected with all kinds of things means that the very small change isn't a small one to test. And in particular, it isn't a small one to fix, as one (or more) of the connections were completely dismissed in the implementation. There's a very relevant, common use case that just wasn't in the focus of the change now.
So, small batches to some may be bigger to some others. And these surprises in how they are sized up are causing the waiting problems, as one has already "moved on", when more work on the same small thing arrives. The developer never committed to complete the value, just his idea of what tasks would be needed to deliver the value. And he is mentally engaged on the other tasks already when he is told, with examples, that it just isn't done yet. The message is not welcome, leading to a wait time.
This all is a vicious cycle. It eats away morale of us all. The tester, the developer, the manager. None of us is happy. So how we don't get it changed is a mystery to me.
There culture includes a "need for speed". Doing things continuously, incrementally fast. Just add more. Change it. And don't break it while changing. There's no test automation to support this. The building block of speed is the developer, who is pushed for finding a minimal solution that could be delivered quickly. The ideas of someone testing are new and are mostly making things worse. The time was already up by time of delivery, and now the poor developer has fixes to create, while feeling the pressure of the next quick feature is the queue. And often not just the external pressure but also internal - the next feature is more fun that fixing the old one.
Let me look at a small batch from one more angle. A really small batch without big testing implications that would look like an hour of work - it takes three days. Or in other words, a work week fits just two of those types of issues. When a developer is pressured with time, they learn to protect their other interests. The motivation is low as you're all alone with your assigned task, and you might not have the skills to come up with a solution. The first day goes into just procrastinating with the idea of having to do this. Google a little, read whatever you find, talk to your colleagues. Not directly on the matter of course, otherwise they might say that you're not good enough. The second day you try out some of the stuff and none works. On third day you ask directly someone who knows and can complete the task in an hour. And after the other developer did the actual bit, you spend time testing, checking and finalizing, as your name will still go on the fix.
I believe that while the idea of small batches is great, the relevant bit here is to do something about developer happiness, motivation and skills. There's a reason for any of us rather spending time procrastinating than working efficiently towards delivering the value. The pairing and other changes I suggest threatens the hidden self-development time. It threatens the permission to work remotely and not talk to your team mates for days. But it also holds a lot of potential to make us happier, all of us in the team.
How many "small batches" does your work week fit? Doesn't the whole concept of small batches make you feel bad about not completing so many of them in your week? I love the idea for trying to split things rationally from a value perspective, but I hate the work monitoring implications.
Not all batches and skills needed in them are equal. Not all days for a professional are equal. I'm great at procrastinating, letting my mind wander and building connections that wouldn't be immediately relevant for the task at hand. But the stuff I'm learning and realizing while at it, makes a big difference in the end result. But I also finish the work. Sometimes when I was supposed to. Sometimes early, sometimes later. Motivation and feeling the purpose make a big difference on whether a small batch is small in actual calendar time.
