An Alternative for 'Less Relevant' Agile: the Studio Model (forbes.com) 92
Last week Forbes ran an article by writer/data scientist Kurt Cagle arguing that Agile software development "was becoming less and less relevant." Within five days it had racked up 300,000 hits, and "I'm still digging out from the deluge of email, Tweets and Linked In messages," he wrote this week.
But in a new follow-up, Cagle looks back over his 40 years of programming, remembering successful six-month development cycles in the 1990s that used "a home-grown methodology which I've since dubbed the Studio Model, because it reflected the way that you create movies, television programs, orchestrated concerts, video games, and to be honest, most intellectual property." He then attempts a 12-point manifesto for this Agile alternative, which emphasizes things like a clear vision, good design, redundancy, flexibility, and remembering that as a project moves forward changes become "exponentially expensive". All too often, proponents of certain methodologies want to claim that their methodologies are the reason for success, when in reality, the deciding factor was the skill and tenaciousness of the people involved, the presence of a clearly articulated vision that could be changed as needed but that was not written in jello, and on recognizing the distinction between providing flexibility and fueling failures.
Agile is not, by itself, a methodology. The Agile Manifesto is a wish-list, written primarily by programmers, in response to the incessant micro-management by non-technical managers who were in general too incompetent to learn about the technology that they managed. I cheered when I first read it... Agile legitimized the idea that all stakeholders must be involved in the process of shaping the product's constraints and parameters (something that even now is still more preached than practiced). It gave a voice to developers and (some) others in the production process who up until then often had little say, and its message to managers in particular about the need to trust in the competence of the people they manage is one that cannot be stressed loudly enough. Its emphasis on change management has spurred a lot of thought about the nature of change, experimentation and development costs in the field. And for all that I think that certain Agile tools are a bit on the cheesy size, the idea of formalizing the process of development in such a way as to give creatives both the opportunities and the tools to shape and push back on design decisions is invaluable.
Yet, there are two key sets of problems that the Agile community faces. The first, and foremost, is that it decentralizes responsibility too much -- it essentially punts on the whole issue of governance or editorial guidance. This is that whole vision thing all over again... Agile empowers autonomous teams, but those teams still need to be able to pull together towards a common set of goals, and this means sacrificing some autonomy for cohesiveness. Agile also does not (ironically) distribute very well for precisely that same reason...
Agile may be everywhere, as several readers suggested, but scratch the surface a bit and you'll find that most of those successful agile projects were ones where you had a strong architect or steward, a culture that was already primed to work in a more Studio-Model like manner, a strong design in the first place as a foundation, and exceptional team-members that used agile in the way it should be used -- as a scaffold, rather than a crutch. There are good things to take out of the last twenty years of Agile, but this is not 2000, and it's well past time to acknowledge what's worked with Agile ... and what hasn't.
But in a new follow-up, Cagle looks back over his 40 years of programming, remembering successful six-month development cycles in the 1990s that used "a home-grown methodology which I've since dubbed the Studio Model, because it reflected the way that you create movies, television programs, orchestrated concerts, video games, and to be honest, most intellectual property." He then attempts a 12-point manifesto for this Agile alternative, which emphasizes things like a clear vision, good design, redundancy, flexibility, and remembering that as a project moves forward changes become "exponentially expensive". All too often, proponents of certain methodologies want to claim that their methodologies are the reason for success, when in reality, the deciding factor was the skill and tenaciousness of the people involved, the presence of a clearly articulated vision that could be changed as needed but that was not written in jello, and on recognizing the distinction between providing flexibility and fueling failures.
Agile is not, by itself, a methodology. The Agile Manifesto is a wish-list, written primarily by programmers, in response to the incessant micro-management by non-technical managers who were in general too incompetent to learn about the technology that they managed. I cheered when I first read it... Agile legitimized the idea that all stakeholders must be involved in the process of shaping the product's constraints and parameters (something that even now is still more preached than practiced). It gave a voice to developers and (some) others in the production process who up until then often had little say, and its message to managers in particular about the need to trust in the competence of the people they manage is one that cannot be stressed loudly enough. Its emphasis on change management has spurred a lot of thought about the nature of change, experimentation and development costs in the field. And for all that I think that certain Agile tools are a bit on the cheesy size, the idea of formalizing the process of development in such a way as to give creatives both the opportunities and the tools to shape and push back on design decisions is invaluable.
Yet, there are two key sets of problems that the Agile community faces. The first, and foremost, is that it decentralizes responsibility too much -- it essentially punts on the whole issue of governance or editorial guidance. This is that whole vision thing all over again... Agile empowers autonomous teams, but those teams still need to be able to pull together towards a common set of goals, and this means sacrificing some autonomy for cohesiveness. Agile also does not (ironically) distribute very well for precisely that same reason...
Agile may be everywhere, as several readers suggested, but scratch the surface a bit and you'll find that most of those successful agile projects were ones where you had a strong architect or steward, a culture that was already primed to work in a more Studio-Model like manner, a strong design in the first place as a foundation, and exceptional team-members that used agile in the way it should be used -- as a scaffold, rather than a crutch. There are good things to take out of the last twenty years of Agile, but this is not 2000, and it's well past time to acknowledge what's worked with Agile ... and what hasn't.
