Kallokain

Simplified Goal Map showing three top level project/program goals, linked to a business goal. Welcome to Part Four in the (as originally planned) three part series on high level controls for large software development projects. First, a brief recapitulation of the first three parts of this series: In the first part I wrote about how using Cost and Capacity to control an agile software project can trap an organization in a hire and fire cycle that increases project duration and cost. In the second part , I wrote about how to optimize a project for delivering maximum business value . I also wrote about a common mistake companies do, which will disable the Business Value lever, so it no longer works as intended. In the third part , I described a very common set of levers called The Iron Triangle. I also described a set of four levers used in the original version of Extreme Programming. I showed that both of these models have their pros and cons. Both can be useful, but neither is

  Agile software development requires significant long term investments in developer skill. Most “Agilists” choose not to talk about it. I had just begun working on part four in my three part blog post series Are You Still Using the Wrong Control Levers in your Agile projects? , when I found myself writing a section about agile project economics. The section was rather long, and didn’t quite fit with the rest of part four, so I decided to break it out, and make it a separate blog post instead. This is it! I do hope you enjoy reading it. In case you wonder why there are four parts (five if you count this interlude) in a three part blog post series, well, requirements changed, and the scope increased… Agile methods have great benefits, both in human, and economic terms. There are also costs. Thus, going agile, if it is done seriously, requires thinking a bit about the trade-offs that must be made. Most companies don’t consider the trade-offs. What they do is they set up an “Agile tr

  Welcome back! Or, if this is the first time you visit, welcome! It’s been awhile since I wrote the first two parts in this series about high level project control levers, their use, and abuse. This is the third and final part. In it, we will have a look at two control lever systems, the classic Iron Triangle, and the somewhat less well known Four Lever system from the first edition of Extreme Programming. First, a brief recapitulation of the first two parts of this series: In the first part I wrote about how using Cost and Capacity to control an agile software project can trap an organization in a hire and fire cycle that increases project duration and cost. In the second part , I wrote about how to optimize a project for delivering maximum business value. I also wrote about a common mistake companies do, which will disable the Business Value lever, so it no longer works as intended. You can read each part, including this one, as a standalone article. To get as complete an understan