Uncategorized

Fixed time, variable scope

Just like content development in any other medium, software development reduces to the elimination of entropy. Unlike other media, however, there is very little else to count. The problem is that you and/or your team can only eliminate a fixed-ish number of bits of entropy per unit time, and at the outset you don’t know how many bits there are in the problem to eliminate. So you say we’re gonna work this much, and whatever comes out the other end of that process is whatever you get. In the current theory, and sometimes in practice, this is how sprints are supposed to work, and the material that doesn’t fit is accumulated into some backlog or other.

– Dorian Taylor, Agile as Trauma

Standard

One thought on “”

  1. Ryan

    This article is chock full of bangers.

    In 20 years, Agile has given us standup meetings, sprints, pair programming, user stories, DevOps, and continuous integration. This is all tactical stuff. Contracting gets a little attention, but nothing like the attention heaped onto project management on down. Where are the people thinking and talking about Agile procurement, for example? Or Agile enterprise resource planning? This is important, because failures to implement Agile principles are often easily diagnosed as side effects of the constraints of antiquated procurement and contracting practices.

     

    So much effort goes into writing and talking about collaboration, and creating tools to facilitate collaboration and telecollaboration, with the tacit assumption that more collaboration is always better. To quote Frederick Brooks, the more collaboration the better is far from a self-evident proposition and certainly not universally true. True indeed, to the extent that collaboration divides labour, but questionable as a fraction of one’s activity. Since communication overhead increases proportionally the square of the number of people on the team—a fact illuminated by Brooks in the 1970s—what you actually want is as little collaboration as you can get away with.

     

    Any Agile adherent can tell you that Waterfall is bad, and that if you aren’t doing Agile, you must necessarily be doing Waterfall. It is clear, however, that comparatively few have actually read the 1970 Waterfall paper. If they had, they would learn that what they had experienced—or more likely, heard about—was what the paper’s author asserted was the wrong way to manage a software project.

     

    A development paradigm that can be construed from the outside as setting great store by speed—or, I suppose, velocity—is invariably going to be under continuous political and economic pressure to accelerate. It isn’t clear from the literature that this was anticipated by the Manifesto’s signatories. If instead you asserted that the work amounts to continual discovery, it happens at one speed, and could potentially continue indefinitely, you might be able to pace yourself.

Leave a Reply

Your email address will not be published. Required fields are marked *