Disciplined Agile

We recently published an article describing how the Disciplined Agile Delivery (DAD) framework is being extended to cover Portfolio Management activities.  The following diagram depicts the DAD goal diagram for Portfolio Management, and as you would expect your organizations has a range of options to choose from.  In this diagram we use the term endeavor to refer to a project, product, or experiment.

The article describes each one of these process factors – Identify Endeavors, Explore Potential Endeavors, and so on – in greater detail.  A future version of the article will describe the strategies/practices associated with each factor.  We have also included a high-level workflow diagram, see below, to overview from the point of view of the Portfolio Management process blade how it fits into the rest of the Disciplined Agile (DA) toolkit.

An interesting aspect of the flow diagram is that it shows the relationship of Portfolio Management to other IT Plan activities.  For example, Enterprise Architecture provides a Technology Roadmap and Product Management provides a Business Roadmap and an indication of stakeholder priorities – all critical information that are inputs into the efforts around prioritizing potential endeavors.  The point is that this diagram reflects workflow, not organizational design.  For example, in some companies there is no Product Management team, instead responsibility for the Product Management activities are spread out amongst several teams.  A common strategy is to have the Portfolio Management team responsible for understanding stakeholder priorities and the Enterprise Architecture team responsible for the business roadmap.  Another approach would be to have the Portfolio Management team subsume both of those activities.  A third approach would be to have three teams, one for each of Enterprise Architecture, Product Management, and Portfolio Management.  Different organizations will make different organizational design decisions, and of course these decisions will evolve over time.  As always, context counts.

I hope that you find the more detailed Portfolio Management article to be of interest.

I’m writing this from the Agile Business Conference in London where I did a talk on DAD yesterday. Unfortunately I didn’t have much time to go into DAD in depth. A gentleman approached me today, saying that he is very interested in learning more about DAD but is not sure why it is needed with all the other methods out there,

This is a very good question, and I guess I should have been more clear in my talk. First of all, DAD is not a new method, but rather a general framework from which you can pick some “good ideas” which might makes sense for your organization or project. It also adds some structure that is missing from most agile methods. Here are some reasons that we think that the toolkit is worthwhile:

• DAD is a hybrid of leading agile methods, bringing together a set of complimentary practices from methods such as Scrum, XP, Agile Modeling, Lean, & the Unified Process
• most existing methods such as Scrum, do not have practices related to the full lifecyle (by design). Scrum for instance is focused mainly on management, rather than say, architecture. DADs hybrid approach harvests leading practices from across the lifecycle
• DAD goes beyond agile rhetoric and acknowledges that certain enterprise practices don’t go away with agile, such as the need to collaborate with other projects, enterprise authorities such as architecture, database , and PMOs
• an explicit recognition that most enterprise projects go through startup (Inception) and deployment (Transition) phases
• DAD avoids branded terminology such as “sprint” and rather uses common sense terminology that is understandable regardless of one’s methodology preference

DAD is meant to help promote and simplify proven agile practices, not replace them.  Rather than having to say “our shop does Scrum, with some XP practices, a bit of Kanban, etc…”, why not say that you are using DAD? You can choose from any of the techniques from these methods without some agilist criticizing you that “you are not doing Scrum actually because it doesn’t believe in the XYZ practice that you are using from ABC method”

If you are doing Scrum now, for instance, you could currently say that you are using DAD, as its guidance is a subset of practices you could use in DAD, As you add agile capability, and want accelerate your projects and increase quality, or add some required scaling techniques, you could draw additional ideas from DAD. BUT only if required and makes sense for you.

In summary, DAD provides a breadth of non-prescriptive guidance (good ideas that MIGHT make sense for you) with non-branded ideas that go beyond traditional agile methods to help deal with enterprise considerations that are a reality on most non-trivial projects.