Agile Zone is brought to you in partnership with:

Matthias Marschall is a software engineer "Made in Germany". His four children make sure that he feels comfortable in lively environments, and stays in control of chaotic situations. A lean and agile engineering lead, he's passionate about continuous delivery, infrastructure automation, and all things DevOps. Matthias is a DZone MVB and is not an employee of DZone and has posted 38 posts at DZone. You can read more from them at their website. View Full User Profile

3 Reasons To Avoid Overloading Your Teams

04.19.2013
| 10485 views |
  • submit to reddit

Monday morning on the highway. Your speed: 0 mph. You’re stuck in the usual rush hour traffic jam because the capacity of this road is exceeded. And it’s now obvious you’ll reach your destination much later than if the road were empty.

But what happens if you exceed the capacity of your development team? What happens when you cram in more features than the team can develop? Your features will get stuck in development. Let’s see how this can happen.



What happens if you push too many features into your development pipeline?

Let’s discuss three negative outcomes of overloading your pipeline:

  1. You lose focus by increased task switching
  2. Managing the waiting queue costs a lot of time
  3. Big releases create big headaches

Having too much upcoming work leads to task switching

When an avalanche of requirements hits, you have the urge to do everything in parallel because everything is important. You dutifully start with the most urgent task, only to have the second most important thing blow up in your face. Switching focus to the new number one in your list lets you watch the next three things go off like an ill-timed firework display.

When you’re constantly switching from one task to the next, you’ll hardly finish any one of them. Every single task stays on your todo list longer than it should. And I’m not even talking about the time you lose adjusting to every new task. Just the fact that you’re hopping from task to task increases the lead time of each dramatically. Instead of getting your overloaded pipeline cleaned up, more and more stuff piles up in front of you.

The second problem is managing the waiting queue.

If more and more stuff piles up, you waste time managing that queue

Again and again, you revisit and re-prioritize your ever growing list of tasks. Every time you go through that list you need to remember the details of each item, it’s current status, and so on. This takes a lot of mental energy and a considerable amount of time. That time and energy are lost instead of used to finish things.

And while you’re not getting anything done, guess what? That todo list grows longer and longer resulting in even more queue management work. A vicious cycle which is only made worse with today’s tools. We’ve got a host of bug tracking tools which let you manage hundreds or even thousands of open issues. I was once very proud of having over 1400 open issues sitting in our bug tracker. But it was an ordeal to go through even the upper part of that list again and again. We finally scrapped it and never looked back.

And that brings us to the third ill effect of overloading your development pipeline: big releases.

Dealing with too many features in parallel means preparing big releases

And assembling big releases means a lot of complexity. This complexity increases management overhead and reduces quality because no single person has a complete overview anymore.

Instead of knowing exactly what went live (and what might have caused a certain bug), you’ve got a big batch of stuff going live all at once and no chance of ever finding out why something broke. This is a very bad situation.

But it gets even worse than that: with growing complexity, I’ve found the number of bugs increase more than just proportionally. That means if you’re releasing double the amount of features, you’ll have to deal with way more than double the problems. Remember that nice task list – your “development pipeline”? Feel free to cram these release issues right on top.

“Yes, quality issues are clogging my pipeline, but there’s nothing I can do about it”

I know, it looks like that. But I’ve seen teams move from big releases with weeks of stabilization phases to continuous deployments. By creating a pull system and focusing on flow it is possible to break the vicious cycle.

These things get you into a vicious cycle

If you overload your pipeline, things will get worse because of more task switching, increased management overhead to manage your todo lists, and the unfortunate dynamics of big releases.

Create a pull system and focus on flow to break that vicious cycle and you’ll never feel like being stuck on the highway during rush hour.

What are your experiences with having too much stuff to do? Please share it with us in the comments.

Published at DZone with permission of Matthias Marschall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)