Theory Of Constraints: Productivity Metrics in Software Development

In the past, I’ve been a true believer that software development is not really possible to measure from a productivity perspective. I was ignorant, basically. I’m now a bit wiser and I understand that software development is no different than any other product development process. We can and should measure productivity of software developers by understanding that we are building business value via functionality that the end-user wants. So, we should essentially be measuring our progress toward the end user facing functionality (as an over-simplification).

A Paper On The Theory Of Constraints

Several months ago, I wrote up a paper for an internal company effort to help define productivity metrics for software developers. This paper is largely based on the work of David J. Anderson, in “Agile Management For Software Engineering”. It also includes some of my own interpretations and understandings of the Theory of Constraints.

The original intent of this paper was to facilitate the discussion of productivity and metrics in the Development Department at McLane Advanced Technologies, LLC., where I work. I decided to release it to the world, to hopefully help others understand how we can measure productivity as software developers. I did not intend this to be a comprehensive or exhaustive discussion of the points within, but am trying to spur additional research and conversations. I hope you enjoy reading it as much as I enjoyed writing it.

Download The Paper

You can download the PDF here:

The Theory of Constraints: Productivity Metrics In Software Development


Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in E-Books, Metrics, Productivity, Theory Of Constraints, Throughput. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Chintoo Patel

    Good insight into the business aspect of software development. Anyone aspiring to be more than just a code monkey should read. Thanks for sharing!

  • http://softwareservices.techndu.com robertclaye

    good blog…. I understand that software development is no different than any other product development process. We can and should measure productivity of software developers by understanding that we are building business value via functionality that the end-user wants.

  • Joe Fiorini

    Hey Derek, tried to download your paper linked in this article, but got a 404. Is there another download link for it? Thanks!

    • http://mutedsolutions.com Derick Bailey

      it must have been missed during the migration to WordPress, recently. I’ll find it and re-post it.

    • http://mutedsolutions.com Derick Bailey

      Joe – the link has been fixed, and you should be able to download the file now.

  • public

    Could you clarify between the two definitions of Inventory in your paper. You write in the Inventory section that inventory is any unit of work that “is not actively being worked on.” But you write in the Quantity section that “any feature or function that is not delivered
    to the customer yet, is considered inventory.” Is inventory everything not being worked, or everything not delivered according to this model? Thanks!

    • http://mutedsolutions.com Derick Bailey

      anything that has been started (including design, detailed requirements gathering, etc), but not delivered. the first statement is slightly wrong… it does fit within the right definition, but it’s too narrow / constrained. the second statement is more accurate.