Just a delivery lifecycle?
I was recently asked a question around the scope of the DAD lifecycle and thought that I would share my answer publicly.
The focus of DAD is the delivery portion of the solution lifecycle, from initiation to delivery into production (or the marketplace in the case of a commercial product). Any given solution will go through the delivery portion of the lifecycle many times during it’s existence as releases are put into production.
BUT, this isn’t the entire solution lifecycle. For example:
- There are some portfolio management activities before a project starts such as project identification and selection that are outside the scope of DAD. We show this as input into the DAD lifecycle to help provide context.
- There are also post-delivery activities, particularly operations and support, that are part of the overall solution lifecycle but outside of the delivery portion of the lifecycle. In DAD we explicitly show feedback coming back from the production portion of the solution lifecycle because this is a common occurrence.
Note that these comments apply to both the basic (Scrum-like) version of the lifecycle as well as the advanced/lean version. Because DAD explicitly recognizes that your process improvement activities will include changes that affect the lifecycle, we don’t enforce a single DAD lifecycle.
I had experience in recent project which had more than 30 people in addition to relevant stakeholders. I have asked to implement Scrum but the prerequisites of its implementation were not satisfied.
DAD embodies Scrum by forming teams for this medium size project (according to DAD definition and relaxing some of the strict team requirements of Scrum.
For me DAD would have served as a road-map or place-holder for organizing Agile projects which the delivery of software is done via Scrum teams.
I’ve seen a software project where some people on the project itself were asked to do the maintanance on the software. Sounded like a good idea from a knowledge management perspective. But the people didn’t want it, they just wanted to keep building neat stuff and liked the vivid nature of a project.
This sort of was the organisations solution to the devops problem. I like the concept of defining a strict lifecycle beginning, end and feedback from the production environment. I do wonder how often software is maintained by a seperate team as it was built with. I do like the concept of bringing in a maintance guy helping to develop the application knowing he is also the guy who is gonna maintain it. This makes sure the team doesn’t shortcut some areas, because the maintance guy probably will slap them