It's Not Developers Slowing Things Down, It's the Process

Posted by Soulskill on Friday November 21, 2014 @04:50AM from the it's-not-the-heat,-it's-the-humidity dept.

An anonymous reader writes: Software engineers understand the pace of writing code, but frequently managers don't. One line of code might take 1 minute, and another line of code might take 1 day. But generally, everything averages out, and hitting your goals is more a function of properly setting your goals than of coding quickly or slowly. Sprint.ly, a company than analyzes productivity, has published some data to back this up. The amount of time actually developing a feature was a small and relatively consistent portion of its lifetime as a work ticket. The massively variable part of the process is when "stakeholders are figuring out specs and prioritizing work." The top disrupting influences (as experienced devs will recognize) are unclear and changing requirements. Another big cause of slowdowns is interrupting development work on one task to work on a second one. The article encourages managers to let devs contribute to the process and say "No" if the specs are too vague. Is there anything you'd add to this list?

1 of 186 comments (clear)

Min score:

Reason:

Sort:

Re:Agile is supposed to fix these things by JohnFen · 2014-11-21 06:26 · Score: 1, Informative

Yes, those are the ideals of agile. But I have never seen any of them successfully done in the real world. Instead agile as implemented (which never resembles the ideal) just makes everything worse.