DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

3 Reasons To Avoid Overloading Your Teams

[deleted] user avatar by
[deleted]
·
Apr. 19, 13 · Interview
Like (1)
Save
Tweet
Share
12.75K Views

Join the DZone community and get the full member experience.

Join For Free
daily traffic by burning image
creative commons license burning image

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.

teams Task (computing)

Published at DZone with permission of [deleted], DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Java Code Review Solution
  • A Beginner's Guide to Infrastructure as Code
  • Custom Validators in Quarkus
  • Secure APIs: Best Practices and Measures

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: