How best to manage development jobs? The ancient assumption is to treat the work as a whole product in the form of a project, one of the most resilient and biggest ideas (assumption) underlying high-tech development.
The following posts (via the Agile Chronicles Newsletter) challenge this idea of the 'one big thing' that everyone works on.
Teams over Projects by Brian Bozzuto (June 27, 2011)
You may find this counter-intuitive, but I would posit that many traditional organizations use broad project portfolios as a means of achieving agility. With the heavy ramp up costs of any given project, having multiple options to respond to change. We can ramp up or down our energy on any given project based on changing circumstances or priority. While it’s not terribly flexible, it does offer some level of adaptability. However, it comes at the price of running all these projects at the same time, which is a very steep tax when you start adding up the cost of multiple status reports, daily or weekly meetings, code branches, design documents and any other overhead required for running your projects...
Do You Have Feature-itis? by Johanna Rothman (July 22, 2011)
Feature-itis. It’s an agile Product Owner game. It’s when the Product Owner says, in his or her best George Carlin voice, “Gimme Features. I don’t care about no stinkin’ framework.
Kanban, Scrum/XP and the Paradox of Constraints by Jim Bird (July 13, 2011)
If you find it difficult to break your work into time boxes, if your work is highly interrupt-driven like in many maintenance and support shops, then Kanban offers an alternative control structure. I am not sure that I buy into its manufacturing control-line metaphor, and that all of these ideas map well from manufacturing to the highly variable work involved in building and supporting software.
