Smart Agile Delivery

10 years, 5 months ago

Smart Agile Delivery

by

I was interested to read the recent McKinsey report on disruptive technologies. McKinsey identifies twelve potentially economically disruptive technologies including the Mobile Internet, Automation of Knowledge work, Internet of Things, Advanced Robotics, Next generation genomics and so on. The report also calls out general purpose technologies as ones that propel steep growth trajectories (think Steam or Internet) – that can be applied across economies and leveraged in many more specific disruptive technologies. Not surprisingly they don’t include software development in either list. The closest they come is with the automation of knowledge work, but this is restricted to artificial intelligence, machine learning and natural interfaces like voice recognition that automate many knowledge worker tasks that have long been regarded as impossible or impracticable for machines to perform.

Is this omission something we should be concerned about I wonder? While software development “practices” have been developing very rapidly with the adoption of Agile methods, it is a reasonable conclusion that software development “technologies ” are not undergoing dramatic changes that might qualify as disruptive. Yes there’s lots going on; in fact there’s a profusion of new languages, frameworks and databases, many open source initiatives, that are progressively specializing development technology. In addition there are significant advances in life cycle management and test technologies. But there isn’t any indication that these new technologies will have high economic impact in terms of dramatic improvement in productivity or quality. Or have a significant impact on the vast economic problem inherent in the worlds legacy systems. Rather there’s a huge proliferation of development diversity and some might say complexity.

Don’t get me wrong, I am not looking for a problem to solve. It’s clear that while smaller Agile projects are fine for tightly targeted problems, most organizations have struggled to scale Agile to larger projects and or enterprise class projects. The increase in dependencies and complexities become overwhelming and the probability of failure increases proportionately.

What’s needed, by larger projects is not process automation, but automation of the deliverable that allows the project to manage the dependencies at the model AND deliverable level. This raises the level of abstraction and can deliver dramatic productivity and quality improvements. As it happens there is a technology that can do this, but strangely it seems to be something that many people have already consigned to the trash heap of “been there done that”. I’m talking about Model Driven Development (MDD). There are many reasons why MDD has not succeeded in gaining widespread acceptance. It is actually extremely complex and requires considerable investment to establish. And in fairness it has been promoted primarily as a deliverable transformation and code generation tool. And many people will say, Oh NO!!! That’s just reinventing Case Tools all over again and we don’t want to go there.

But before we consign this technology to the trashcan of yesterday’s technologies, we need to take a hard look at what you can do if:
A. you have leaf node detail models in the asset repository that are tightly bound to execution deliverables.
B. you use best practice modern architecture with all functionality delivered as service bearing capabilities that minimize dependencies.
C. you can automate to a significant extent the population of the repository with harvested knowledge about legacy applications at that same leaf node level of detail.
D. you can run large scale, full life projects with full iteration of business, architecture, design and development models. (note here this doesn’t mean fully integrated and transformed models, we have gotten a lot cleverer over the years.)
In an Agile context this allows you to iterate functionality at extremely low cost, both in delivery and evolution life cycle stages. In fact experience shows it transforms the development project into an evolutionary approach in which you can really architect and build what you know and evolve to the optimal solution.

Model driven as a concept has been around a long time. Most developers (tell me they) don’t like model driven because it won’t handle complexities; because it diminishes developers’ jobs to be more mundane; that it produces poor code and so on and so forth. But the McKinsey report speaks to the inexorable progress of technology and the inevitability that as technology changes peoples jobs change or disappear. You are either on the train or under it.

Right now Agile MDD is probably only justifiable for the very large, complex projects. But as the case studies start showing higher success rates, with dramatic increases in productivity and quality, and the level of up-front investment is reduced as the capability is productized, we can expect to see the MDD project footprint to expand dramatically. Again the McKinsey report is incredibly bullish on the economic outlook for technology, and information technology in particular as the key general purpose enabling technology, and it’s clear that Agile processes alone are inadequate to support the ever increasing demand.

Being disciplined is for school kids; it’s time we got smart about how we deliver complex services and systems at scale.

McKinsey & Company: Disruptive technologies: Advances that will transform life, business, and the global economy. “Not every emerging technology will alter the business or social landscape—but some truly do have the potential to disrupt the status quo, alter the way people live and work, and rearrange value pools.”

10 years, 5 months ago

Smart Agile Delivery

by

I was interested to read the recent McKinsey report on disruptive technologies. McKinsey identifies twelve potentially economically disruptive technologies including the Mobile Internet, Automation of Knowledge work, Internet of Things, Advanced Robotics, Next generation genomics and so on. The report also calls out general purpose technologies as ones that propel steep growth trajectories (think Steam or Internet) – that can be applied across economies and leveraged in many more specific disruptive technologies. Not surprisingly they don’t include software development in either list. The closest they come is with the automation of knowledge work, but this is restricted to artificial intelligence, machine learning and natural interfaces like voice recognition that automate many knowledge worker tasks that have long been regarded as impossible or impracticable for machines to perform.

Is this omission something we should be concerned about I wonder? While software development “practices” have been developing very rapidly with the adoption of Agile methods, it is a reasonable conclusion that software development “technologies ” are not undergoing dramatic changes that might qualify as disruptive. Yes there’s lots going on; in fact there’s a profusion of new languages, frameworks and databases, many open source initiatives, that are progressively specializing development technology. In addition there are significant advances in life cycle management and test technologies. But there isn’t any indication that these new technologies will have high economic impact in terms of dramatic improvement in productivity or quality. Or have a significant impact on the vast economic problem inherent in the worlds legacy systems. Rather there’s a huge proliferation of development diversity and some might say complexity.

Don’t get me wrong, I am not looking for a problem to solve. It’s clear that while smaller Agile projects are fine for tightly targeted problems, most organizations have struggled to scale Agile to larger projects and or enterprise class projects. The increase in dependencies and complexities become overwhelming and the probability of failure increases proportionately.

What’s needed, by larger projects is not process automation, but automation of the deliverable that allows the project to manage the dependencies at the model AND deliverable level. This raises the level of abstraction and can deliver dramatic productivity and quality improvements. As it happens there is a technology that can do this, but strangely it seems to be something that many people have already consigned to the trash heap of “been there done that”. I’m talking about Model Driven Development (MDD). There are many reasons why MDD has not succeeded in gaining widespread acceptance. It is actually extremely complex and requires considerable investment to establish. And in fairness it has been promoted primarily as a deliverable transformation and code generation tool. And many people will say, Oh NO!!! That’s just reinventing Case Tools all over again and we don’t want to go there.

But before we consign this technology to the trashcan of yesterday’s technologies, we need to take a hard look at what you can do if:
A. you have leaf node detail models in the asset repository that are tightly bound to execution deliverables.
B. you use best practice modern architecture with all functionality delivered as service bearing capabilities that minimize dependencies.
C. you can automate to a significant extent the population of the repository with harvested knowledge about legacy applications at that same leaf node level of detail.
D. you can run large scale, full life projects with full iteration of business, architecture, design and development models. (note here this doesn’t mean fully integrated and transformed models, we have gotten a lot cleverer over the years.)
In an Agile context this allows you to iterate functionality at extremely low cost, both in delivery and evolution life cycle stages. In fact experience shows it transforms the development project into an evolutionary approach in which you can really architect and build what you know and evolve to the optimal solution.

Model driven as a concept has been around a long time. Most developers (tell me they) don’t like model driven because it won’t handle complexities; because it diminishes developers’ jobs to be more mundane; that it produces poor code and so on and so forth. But the McKinsey report speaks to the inexorable progress of technology and the inevitability that as technology changes peoples jobs change or disappear. You are either on the train or under it.

Right now Agile MDD is probably only justifiable for the very large, complex projects. But as the case studies start showing higher success rates, with dramatic increases in productivity and quality, and the level of up-front investment is reduced as the capability is productized, we can expect to see the MDD project footprint to expand dramatically. Again the McKinsey report is incredibly bullish on the economic outlook for technology, and information technology in particular as the key general purpose enabling technology, and it’s clear that Agile processes alone are inadequate to support the ever increasing demand.

Being disciplined is for school kids; it’s time we got smart about how we deliver complex services and systems at scale.

McKinsey & Company: Disruptive technologies: Advances that will transform life, business, and the global economy. “Not every emerging technology will alter the business or social landscape—but some truly do have the potential to disrupt the status quo, alter the way people live and work, and rearrange value pools.”