This blog has been replaced with the page Full Agile Delivery Lifecycles.
“By doing so we explicitly admit that DAD teams will be follow a unique tailoring of the process that best fits their situation, a concept that can be ant-thetical in organizations still clinging to the notion of repeatable processes”
I understand why you categorize this as a downside, but it’s reality. Those organizations that refuse to believe in tailoring are like those that refuse to believe in gravity – they fall at the same velocity the believers do. Anyone who believes that the same process can be used to successfully produce embedded software for medical devices and the next big Facebook game are delusional.
in re “more to the agile SDLC than just those phases”
What distinctions exist between product lifecycle (PLC) and development lifecycle (SDLC)? What delimiters exist? At least with respect to DAD, where does the SDLC begin and end?
Certainly projects, by definition, have a lifecycle, but a project is not a product, and with service oriented architectures and knowledge managed as an asset, software in use and its source code can be recognized as a form of Nonaka’s “explicit” knowledge. Nonaka’s spiral of knowledge (SECI) requires sequence nor begining or end. So I am beginning to wonder whether the term “lifecycle” (which implies birth and death or more generally beginning and end) is inappropriate to software evolution.
in re “repeatable process”
For nearly a century, the benchmark method for repeatable process has been Shewhart’s Statistical Process Control (SPC). SPC is useless in isolation, as a sufferer of OCD might find refolding a napkin useless but repeatable. The goal is not repeatable process but repeatable product. Except in undergraduate studies and corroborating research, repeatable product is not the goal of software engineering; the goal is always to provide something better than has existed. Even porting an app from iOS to Android with no change in functionality has the goal of fitting a product to a new context. That is by Juran’s “fitness for use” definition a quality improvement.
Skip, although it isn’t clear in this posting, I think my Agile SDLC article at http://www.ambysoft.com/essays/agileLifecycle.html makes it clear that solutions/software do in fact have lifecycles. You need to consider the scope of what you’re looking at. If you look at just construction or just delivery (pretty much as this blog posting does) then it isn’t clear if there’s an end. If you look at the complete lifecycle of a solution, from initial idea to system retirement, then clearly it does.
This is a great overview and very interesting reading. And your way of embedding links to other blog postings is simple phenomenal, tying together a complete set of precise, enjoyable texts – together teaching the reader what DAD is and why it makes sense to use it.
Have you ever thought about creating an e-book or uest authoring on other websites?
I have a blog based on the same information you discuss and would really like to have you share some stories/information.
I know my readers would value your work. If you are even remotely interested, feel free to send me an e-mail.
Yes, we have the Disciplined Agile Delivery book which is available both in print and as an ebook. I also publish articles at a variety of sites, including AgileModeling.com, AgileData.org, DDJ.com, and several others.
Fill in your details below or click an icon to log in:
You are commenting using your WordPress.com account. ( Log Out / Change )
You are commenting using your Twitter account. ( Log Out / Change )
You are commenting using your Facebook account. ( Log Out / Change )
You are commenting using your Google+ account. ( Log Out / Change )
Connecting to %s
Notify me of new comments via email.
Notify me of new posts via email.
Enter your email address to follow this blog and receive notifications of new posts by email.
Join 735 other followers
Get every new post delivered to your Inbox.