{"id":1185,"date":"2016-01-05T14:04:29","date_gmt":"2016-01-05T13:04:29","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=1185"},"modified":"2024-03-15T15:18:49","modified_gmt":"2024-03-15T14:18:49","slug":"scott-ambler-interview","status":"publish","type":"post","link":"https:\/\/leanmagazine.net\/issues\/issue12\/scott-ambler-interview\/","title":{"rendered":"The Daddy of DAD \u2013 exclusive interview with Scott Ambler"},"content":{"rendered":"

\"Daddy_of_DAD\"<\/a><\/h2>\n

\u201dDisciplined Agile Delivery (DAD) is a process decision framework that enables simplified process decisions around incremental and iterative solution delivery.\u201d<\/em><\/p>\n

WIKIPEDIA<\/span><\/i><\/h3>\n

To the Agile community, the DADDY of DAD is the Canadian software engineer Scott Ambler. In this interview, he tells us how DAD came to be and when we should use it. His baseline message: \u201cDAD is ongoing work; we are constantly improving and evolving the framework!\u201d<\/em><\/h4>\n
\"Scott
Scott W. Ambler is the Senior Consulting Partner of Scott Ambler + Associates, working with organizations around the world to help them to improve their software processes. He provides training, coaching, and mentoring in disciplined agile and lean strategies at both the project and organizational level. Scott is the founder of the Agile Modeling (AM), Agile Data (AD), Disciplined Agile Delivery (DAD), and Enterprise Unified Process (EUP) methodologies.<\/figcaption><\/figure>\n

The story of the Disciplined Agile Delivery Framework, DAD, goes back 5\u201310 years when Scott Ambler was the chief methodologist for IT at IBM Rational. Having worked in dozens of organizations around the globe to help them understand and apply agile and lean strategies at scale, he and his colleagues noticed some recurring patterns.<\/span><\/p>\n

It was clear that everyone was applying Lean & Agile techniques in their own, unique way, although there were similarities. \u00a0Apparently, the organizations succeeding at Lean & Agile spent a lot of time and effort figuring it out. In other words: at the organization and industry level there was an incredible amount of waste going on resulting from the lack of a coherent, flexible process framework.<\/span><\/p>\n

\u201cAs a matter of fact, very few people could describe what they were actually doing,\u201d Scott Ambler remembers. \u00a0\u201cFor example, when asked what process they were following we\u2019d often hear \u2018We\u2019re doing Scrum\u2019 or \u2018We\u2019re doing Kanban\u2019 as if those were sufficient answers. \u00a0When we looked at what they were actually doing they would have adopted some strategies from Scrum\/Kanban, but also from Extreme Programming, Agile Modeling, Unified Process, and many other sources. \u00a0Very often they would have reinvented ideas from these methods without even knowing it, spending a lot of time and money doing so.\u201d<\/p>\n

\n

Timeline <\/strong><\/h4>\n

The DAD 0.x framework was originally developed at IBM Rational. The focus at the time was on showing how Lean & Agile delivery works from beginning to end and to support the tactical scaling of agile\/lean strategies to address larger teams, geographically distributed teams, regulatory compliance, outsourcing, and both technical and domain complexity. The IBM team worked closely with business partners, including Mark Lines, and was led by Scott Ambler.<\/p>\n

2009\u20132012<\/strong>
\nDAD 0.x framework developed at IBM Rational
\nJune 2012<\/strong>
\nRelease of DAD 1.0; the first DAD book, Disciplined Agile Delivery.
\nAugust 2012<\/strong>
\nDAD site<\/a>
\nOctober 2012<\/strong>
\nIntellectual property of DAD passed over to the Disciplined Agile Consortium
\nAugust 2015<\/strong>
\nDisciplined Agile (DA) 2.x released
\n<\/div>\n

A range of choices<\/b><\/h3>\n

So, what is DAD all about? Scott Ambler and his colleagues characterize it as a process decision framework. \u00a0What they mean by this is that it provides guidance to IT delivery teams \u2014 and now also to IT executive teams \u2014 to help these identify the process-related decisions that need to be made. \u00a0The DA Framework is oriented towards mid-to-large sized enterprises that need to have effective IT departments to support them.<\/span><\/p>\n

\u201cMore importantly it provides a range of choices and the trade-offs associated with those choices,\u201d says Scott Amble. \u201cThis means that people can better tailor their approach to address the context of the situation that they face. \u00a0Because everyone is different \u2013 one process size does not fit all.\u201d<\/span><\/p>\n

\n

The Building Blocks of DAD<\/b><\/h4>\n

Process goals<\/b>. \u00a0<\/span>
\n<\/span>Teams var<\/span>y in size, they vary in the way that they are geographically or organizationally distributed, they vary by the domain and technical complexity that they face, and they vary by the compliancy issues that are relevant to them. \u00a0Furthermore, teams are made up of unique individuals, each of whom has a set of unique skills and experiences. \u00a0As a result every team works different at a detailed level. \u00a0However, at a high level they must still address the same goals or capabilities in order to be successful. \u00a0For example, at the start every team should do some initial requirements scoping, some initial architecture envisioning, some initial planning, and so on. \u00a0How they approach these goals will vary depending on the situation they face. \u00a0The DA framework describes 22 process goals<\/a> that explicitly capture the process-related options available to teams. \u00a0Each goal is visually described by a process goal diagram, effectively a stylized mind map. \u00a0Every goal is described by several process factors, and each process factor by several potential practices or strategies that a team might consider to address that factor. \u00a0These practices and strategies are taken from proven methods such as Scrum, XP, Agile Modeling, and many others. \u00a0<\/span><\/p>\n

Lifecycles<\/b>
\n<\/span>Because every team is in a different situation one lifecycle does not work for every team. \u00a0The DA framework supports four <\/span>full delivery lifecycles<\/span><\/a>: A Scrum-based Basic\/Agile lifecycle; A Kanban-based Lean lifecycle; A Lean Continuous Delivery lifecycle; and an Exploratory lifecycle based on Lean Startup. \u00a0DA 2.0 also supports an IT lifecycle.<\/span><\/p>\n

Process blades<\/b>
\n<\/span>A process blade describes a capability area within the DA framework. \u00a0There are process blades for each of the four lifecycles as well as IT-level capabilities such as Enterprise Architecture, Operations, Portfolio Management, Data Management, IT Governance, and many others.\u00a0<\/div><\/span><\/p>\n

The one-size-doesn\u2019t-fit all philosophy is crucial to DAD. Basically, organizations may use it as they please. \u00a0IT is incredibly complex, and every organization suffers from different pain points in different aspects of IT. \u00a0The DA framework shows how the various aspects of IT fit together, providing explicit guidance as to what issues\/decisions you need to consider and a representative range of options from which to choose. \u00a0<\/span><\/p>\n

\u201dDA doesn\u2019t provide all potential options as that\u2019s simply not possible — while you\u2019ve been reading this article someone, somewhere in the world has come up with a new technique,\u201d Scott Ambler says. \u201cBut it does get you thinking, and it does help you to recognize that you have choices and that each choice has advantages and disadvantages. \u00a0There is no such thing as a best practice, only practices which should be applied in some contexts.\u201d<\/span><\/p>\n

In Scott Ambler\u2019s opinion, there are two things that distinguish DAD from other frameworks:<\/span>
\n\u201dFirstly, the DA Framework provides options and guidance for making effective choices given the context of the situation that you face. \u00a0Most other frameworks prescribe a single way of doing things, limiting their applicability in enterprise-class settings. Secondly, the scope of the DA Framework is critical. \u00a0Too many frameworks focus on one aspect of IT and as a result are locally optimized (at best). \u00a0The DA framework takes a system view of IT, enabling IT organizations to understand and potentially optimize their entire process.\u201d<\/span><\/p>\n

\n

The major <\/b>strengths of the DA framework<\/b><\/h4>\n

\u2026 for development teams
\n<\/b>DAD shows how agile\/lean techniques work from beginning to end. \u00a0It describes how activities such as architecture, testing, analysis, programming, design, and so on fit together from beginning to end in a streamlined manner. \u00a0In short it takes a lot of the mystery out of how agile software development actually works in practice.<\/span><\/p>\n

\u2026 for IT executives
\n<\/b>DAD shows how all aspects of IT work together. \u00a0A huge challenge for IT executives is that the bodies of knowledge or expertise for IT capabilities are disconnected. \u00a0For example, in the enterprise architecture space we have the Zachman and TOGAF frameworks. \u00a0In the analysis space we have the IIBA\u2019s BoK. \u00a0In the data management space we have DAMA\u2019s BoK. \u00a0In the management space we have the PMI and Prince2 BoKs. \u00a0In the operations space we have ITIL. \u00a0And so on and so on and so on. \u00a0These BoKs all have great ideas as well as mediocre ideas. \u00a0They overlap with each other. \u00a0They contradict each other. \u00a0They promote different priorities. \u00a0They are all biased towards their area of focus. \u00a0Most importantly they don\u2019t fit together well. \u00a0Organizations need a bigger picture that provides coherent advice for how it all fits together. \u00a0This is what DA 2.0 brings to the table.\u00a0<\/div><\/span><\/p>\n

Read more<\/i><\/b><\/h4>\n

The <\/span>Disciplined Agile site<\/span><\/a> wh<\/span>ere we actively share and evolve the DA material.
\n<\/span>The <\/span>Disciplined Agile Delivery discussion forum<\/span><\/a> on LinkedIn.
\n<\/span>The <\/span>Disciplined Agile Consortium<\/span><\/a> site that provides links to training, downloadable resources (whitepapers, posters), videos, and the Disciplined Agile certification program.
\n<\/span>The <\/span>Disciplined Agile Delivery<\/span><\/a> book which describes the framework in detail.
\n<\/span>The <\/span>Introduction to Disciplined Agile Delivery<\/span><\/a> book that overviews the framework and works through a case study in a large enterprise.<\/span><\/p>\n

Read article in Lean Magazine on Issuu<\/h2>\n