Disciplined agile delivery: Difference between revisions
Restored revision 1010948664 by Walter Görlitz (talk): WP:YOU, unsourced, POV |
m changed link from Kanban to Kanban (development) (more relevant) |
||
(22 intermediate revisions by 14 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Concept in Agile software development}} |
|||
{{Third-party|date=November 2019}} |
{{Third-party|date=November 2019}} |
||
{{Software development process}} |
{{Software development process}} |
||
'''Disciplined agile delivery''' ('''DAD''') is the software development portion of the |
'''Disciplined agile delivery''' ('''DAD''') is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of [[agile software development]], including [[Scrum (software development)|scrum]], [[agile modeling]], [[lean software development]], and others. |
||
The primary reference for disciplined agile delivery is the book ''Choose Your WoW!'',<ref name=":0">{{cite book|url=http://disciplinedagiledelivery.com/dad-handbook/|title=Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working|last1=Ambler|first1=Scott|last2=Lines|first2=Mark|year=2019|isbn=978- |
The primary reference for disciplined agile delivery is the book ''Choose Your WoW!'',<ref name=":0">{{cite book|url=http://disciplinedagiledelivery.com/dad-handbook/|title=Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working|last1=Ambler|first1=Scott|last2=Lines|first2=Mark|year=2019|isbn=978-1-7904-4784-8|author-link1=Scott Ambler}}</ref> written by [[Scott Ambler]] and Mark Lines. WoW refers to "way of working" or "ways of working".<ref>[https://www.pmi.org/disciplined-agile/books/dad-handbook Book: Choose Your WoW! – Disciplined Agile (DA)]</ref> |
||
In particular, DAD has been identified as a means of moving beyond scrum.<ref>{{cite web|last1=Ambler |first1=Scott |author-link1=Scott Ambler|year=2013 |title=Going Beyond Scrum: Disciplined Agile Delivery |url=http:// |
In particular, DAD has been identified as a means of moving beyond scrum.<ref>{{cite web|last1=Ambler |first1=Scott |author-link1=Scott Ambler|year=2013 |title=Going Beyond Scrum: Disciplined Agile Delivery |url=http://docplayer.net/13268729-Going-beyond-scrum-disciplined-agile-delivery-by-scott-w-ambler-white-paper-series.html}}</ref> According to Cutter Senior Consultant Bhuvan Unhelkar, "DAD provides a carefully constructed mechanism that not only streamlines IT work, but more importantly, enables scaling."<ref>Disciplined Agile Delivery in the Enterprise (Cutter IT Journal, Special Issue, June 2013)</ref> Paul Gorans and Philippe Kruchten call for more discipline in implementation of agile approaches and indicate that DAD, as an example framework, is "a hybrid agile approach to enterprise IT solution delivery that provides a solid foundation from which to scale."<ref>{{Cite report |last1= Kruchten |first1= Philippe |author-link= Philippe Kruchten |last2=Gorans |first2=Paul |date= February 2014 |title= A Guide to Critical Success Factors in Agile Delivery |url= http://www.businessofgovernment.org/report/guide-critical-success-factors-agile-delivery |publisher= IBM Center for the Business of Government |page= 14 |access-date= February 1, 2014 |quote= a hybrid agile approach to enterprise IT solution delivery that provides a solid foundation from which to scale }}</ref> |
||
== History == |
== History == |
||
Scott Ambler and Mark Lines initially led the development of DAD |
Scott Ambler and Mark Lines initially led the development of DAD, and continue to lead its evolution. DAD was developed to provide a more cohesive approach to agile software development; one that tries to fill in the process gaps that are (purposely) ignored by scrum, and one that is capable of enterprise-level scale. According to Ambler, "Many agile methodologies—including scrum, XP, AM, Agile Data, [[kanban (development)|kanban ]], and more—focus on a subset of the activities required to deliver a solution from project initiation to delivery. Before DAD was developed, you needed to cobble together your own agile methodology to get the job done."<ref>Disciplined Agile Delivery Meets CMMI (Cutter IT Journal, November 2013)</ref> |
||
DAD was developed as a result of observing common patterns where agility was applied at scale successfully.<ref>{{cite web|title=Disciplined Agile Delivery|url=http://m.crosstalkonline.org/issues/10/82/|publisher=Crosstalk|access-date=2014-01-31|archive-url=https://web.archive.org/web/20140222100856/http://m.crosstalkonline.org/issues/10/82/|archive-date=2014-02-22 |
DAD was developed as a result of observing common patterns where agility was applied at scale successfully.<ref>{{cite web|title=Disciplined Agile Delivery|url=http://m.crosstalkonline.org/issues/10/82/|publisher=Crosstalk|access-date=2014-01-31|archive-url=https://web.archive.org/web/20140222100856/http://m.crosstalkonline.org/issues/10/82/|archive-date=2014-02-22}}</ref> |
||
In 2015 the |
In 2015 the Disciplined Agile (DA) framework, later to become the Disciplined Agile Toolkit, was developed.<ref>{{cite web |title=Intro to Disciplined Agile |url=https://www.pmi.org/disciplined-agile/introduction-to-disciplined-agile}}</ref> This was called Disciplined Agile 2.x. DAD formed the foundation for DA.{{citation needed|date=July 2019}} A second layer, disciplined DevOps, was added as was a third layer called Disciplined Agile IT (DAIT).{{citation needed|date=July 2019}} These layers, respectively, addressed how to address DevOps and IT processes in an enterprise-class setting. |
||
Disciplined |
Disciplined Agile 3.x was released in August 2017 to introduce a fourth layer, Disciplined Agile Enterprise (DAE), to address the full process range required for business agility.<ref>{{cite book |last1=Ambler |first1=Scott |author-link1=Scott Ambler |last2=Lines |first2=Mark |year=2017 |title=An Executive's Guide to Disciplined Agile |url=http://disciplinedagiledelivery.com/exec-guide-to-da/ |isbn=978-1-5398-5296-4}}</ref> |
||
In December 2018, |
In December 2018, Disciplined Agile 4, now referred to as the Disciplined Agile Toolkit, was released.{{citation needed|date=July 2019}} It focused on a completely revamped description of DAD and a team-based improvement strategy called guided continuous improvement (GCI).{{citation needed|date=July 2019}} |
||
In August 2019, |
In August 2019, Disciplined Agile was acquired by [[Project Management Institute]].<ref>{{cite web|title=PMI Announces Acquisition of DA|url=https://www.pmi.org/about/press-media/press-releases/project-management-institute-announces-acquisition-of-disciplined-agile}}</ref> |
||
== Key aspects == |
== Key aspects == |
||
Many of the challenges that teams are facing are out of scope for scrum and the teams need to look to other methods with overlapping parts and conflicting terminology. DAD attempts to address these challenges by using a people-first, learning-oriented, hybrid approach to IT solution delivery.<ref>{{Cite book|url=http://disciplinedagiledelivery.com/dad-handbook/|title=Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working| |
Many of the challenges that teams are facing are out of scope for scrum and the teams need to look to other methods with overlapping parts and conflicting terminology. DAD attempts to address these challenges by using a people-first, learning-oriented, hybrid approach to IT solution delivery.<ref>{{Cite book|url=http://disciplinedagiledelivery.com/dad-handbook/|title=Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working|last1=Lines|first1=Mark|last2=Ambler|first2=Scott|year=2019|isbn=978-1-7904-4784-8|page=41}}</ref> |
||
=== People-first === |
=== People-first === |
||
Disciplined agile delivery (DAD) identifies that "People, and the way they interact with each other, are the primary determinant of success for a solution delivery team."<ref>{{cite web|url=https://www.ibm.com/developerworks/community/blogs/ambler/entry/disciplined_agile_delivery_an_introduction_white_paper22?lang=en|title=Agility@Scale: Strategies for Scaling Agile Software Development|last=Ambler|first=Scott|work=IBM developerWorks|publisher=IBM Software}}</ref> |
Disciplined agile delivery (DAD) identifies that "People, and the way they interact with each other, are the primary determinant of success for a solution delivery team."<ref>{{cite web|url=https://www.ibm.com/developerworks/community/blogs/ambler/entry/disciplined_agile_delivery_an_introduction_white_paper22?lang=en|title=Agility@Scale: Strategies for Scaling Agile Software Development|last=Ambler|first=Scott|work=IBM developerWorks|publisher=IBM Software}}</ref> DAD supports a robust set of roles (see below section), rights, and responsibilities that you can tailor to meet the needs of your situation. DAD promotes the ideas that team members should collaborate closely and learn from each other, that the team should invest effort to learn from their experiences and evolve their approach, and that individuals should do so as well.<ref>{{cite web|url=http://public.dhe.ibm.com/common/ssi/ecm/en/raw14261usen/RAW14261USEN.PDF|title=Disciplined Agile Delivery: An introduction (white paper), pg 7|publisher=IBM Software|access-date=2014-01-31|archive-url=https://web.archive.org/web/20130529060432/http://public.dhe.ibm.com/common/ssi/ecm/en/raw14261usen/RAW14261USEN.PDF|archive-date=2013-05-29}}</ref> |
||
=== Hybrid === |
=== Hybrid === |
||
DAD is a hybrid toolkit that adopts and tailors proven strategies from existing methods such as [[Scrum (development)| |
DAD is a hybrid toolkit that adopts and tailors proven strategies from existing methods such as [[Scrum (development)|scrum]], [[extreme programming]] (XP), [[Scaled agile framework|SAFe]], [[agile modeling]] (AM), [[Unified Process]] (UP), [[Kanban (development)|Kanban ]], [[outside-in software development]], agile data (AD) and [[Spotify#Organizational development strategy|Spotify]]'s development model. Rather than taking the time to adapt one of these existing frameworks, with DAD all of the effort of combining relevant pieces of each technique has already been done. |
||
=== Full delivery lifecycle === |
=== Full delivery lifecycle === |
||
Line 52: | Line 53: | ||
== Lifecycles == |
== Lifecycles == |
||
Disciplined originally supported an agile (scrum-based) project lifecycle and a Lean (Kanban-based) project lifecycle. It has since been extended to support six lifecycles: |
Disciplined originally supported an agile (scrum-based) project lifecycle and a Lean (Kanban-based) project lifecycle. It has since been extended to support six lifecycles: |
||
# '''Agile'''. A three-phase project lifecycle based on |
# '''Agile'''. A three-phase project lifecycle based on scrum. The phases are Inception (what is sometimes called "Sprint 0"), Construction, and Transition (what is sometimes called a Release sprint). |
||
# '''Lean'''. A three-phase project lifecycle based on Kanban. |
# '''Lean'''. A three-phase project lifecycle based on Kanban. |
||
# '''Continuous |
# '''Continuous delivery: Agile'''. An Agile-based product lifecycle that supports a continuous flow of work resulting in incremental releases (typically once a week). |
||
# '''Continuous |
# '''Continuous delivery: Lean'''. A lean-based product lifecycle that supports a continuous flow of work. |
||
# '''Exploratory'''. An experimentation-based lifecycle based on [[lean startup]] that has been extended to address the parallel development of [[minimum viable product]]s as per the advice of [[cynefin]]. |
# '''Exploratory'''. An experimentation-based lifecycle based on [[lean startup]] that has been extended to address the parallel development of [[minimum viable product]]s as per the advice of [[cynefin]]. |
||
# '''Program'''. A lifecycle for coordinating a team of teams. |
# '''Program'''. A lifecycle for coordinating a team of teams. |
||
Line 61: | Line 62: | ||
== Process goals == |
== Process goals == |
||
DAD is described as a collection of twenty-one '''process goals''', or process outcomes.<ref>{{cite web |
DAD is described as a collection of twenty-one '''process goals''', or process outcomes.<ref>{{cite web |
||
| |
|author=Scott Ambler |author2=Mark Lines |
||
|year=2019 |
|year=2019 |
||
|title=Choose Your WoW! |
|title=Choose Your WoW! |
||
|page=46 |
|page=46 |
||
|url=http://disciplinedagiledelivery.com/dad-handbook/ |
|url=http://disciplinedagiledelivery.com/dad-handbook/ |
||
}}</ref> These goals guides teams through a leaner process decisions |
}}</ref> These goals guides teams through a leaner process to decisions that address the context of the situation they face. It enables teams to focus on outcomes and not on process compliance and on guesswork of extending agile methods. It enables scaling by providing sophisticated-enough strategies to address the complexities you face. |
||
{| class="wikitable" valign="top" |
{| class="wikitable" valign="top" |
||
|- |
|- |
||
! Inception |
! Inception phase !! Construction phase !! Transition phase |
||
|- |
|- |
||
| ''Get the team going in the right direction.'' |
| ''Get the team going in the right direction.'' |
||
Line 78: | Line 79: | ||
| |
| |
||
*Form Team |
*Form Team |
||
*Align with |
*Align with enterprise direction |
||
*Develop |
*Develop common project vision |
||
*Explore |
*Explore scope |
||
*Identify |
*Identify architecture strategy |
||
*Plan the |
*Plan the release |
||
*Develop |
*Develop test strategy |
||
*Develop |
*Develop common vision |
||
*Secure |
*Secure funding |
||
|| |
|| |
||
*Prove |
*Prove architecture early |
||
*Address |
*Address changing stakeholder needs |
||
*Produce |
*Produce potentially consumable solution |
||
*Improve |
*Improve quality |
||
*Accelerate |
*Accelerate value delivery |
||
|| |
|| |
||
*Ensure |
*Ensure production readiness |
||
*Deploy the Solution |
*Deploy the Solution |
||
|- |
|- |
||
! colspan="3" | Ongoing |
! colspan="3" | Ongoing goals |
||
|- |
|- |
||
| colspan="3" | |
| colspan="3" | |
||
Line 104: | Line 105: | ||
|- |
|- |
||
| colspan="3" | |
| colspan="3" | |
||
*Grow |
*Grow team members |
||
*Coordinate |
*Coordinate activities |
||
*Address |
*Address risk |
||
*Evolve WoW |
*Evolve ways of working (WoW) |
||
*Leverage and |
*Leverage and enhance existing infrastructure |
||
*Govern |
*Govern delivery team |
||
|} |
|} |
||
Line 116: | Line 117: | ||
=== Primary roles === |
=== Primary roles === |
||
These five primary roles<ref>{{cite web|url=http://disciplinedagiledelivery.com/roles-on-dad-teams/|title=Roles on DAD Teams|last=Ambler|first=Scott|work=disciplinedagiledelivery.com}}</ref> |
These five primary roles<ref>{{cite web|url=http://disciplinedagiledelivery.com/roles-on-dad-teams/|title=Roles on DAD Teams|last=Ambler|first=Scott|work=disciplinedagiledelivery.com}}</ref> in the disciplined agile delivery are typically found regardless of scale. |
||
* '''Stakeholder'''. Someone who is materially impacted by the outcome of the solution. More than just an end-user or customer, this is anyone potentially affected by the development and deployment of a software project. |
* '''Stakeholder'''. Someone who is materially impacted by the outcome of the solution. More than just an end-user or customer, this is anyone potentially affected by the development and deployment of a software project. |
||
Line 125: | Line 126: | ||
=== Potential supporting roles === |
=== Potential supporting roles === |
||
These supporting roles<ref>{{cite web|url=http://disciplinedagiledelivery.com/roles-on-dad-teams/|title=Roles on DAD Teams|last=Ambler|first=Scott|work=disciplinedagiledelivery.com}}</ref> |
These supporting roles<ref>{{cite web|url=http://disciplinedagiledelivery.com/roles-on-dad-teams/|title=Roles on DAD Teams|last=Ambler|first=Scott|work=disciplinedagiledelivery.com}}</ref> are introduced (sometimes on a temporary basis) to address scaling issues. |
||
* '''Specialist'''. Although most agile team members are generalizing specialists,<ref>{{cite web|title=Generalizing Specialists: Improving Your IT Career Skills|url=http://www.agilemodeling.com/essays/generalizingSpecialists.htm|publisher=Agile Modeling}}</ref> sometimes other specialists are required depending on the needs of the project. |
* '''Specialist'''. Although most agile team members are generalizing specialists,<ref>{{cite web|title=Generalizing Specialists: Improving Your IT Career Skills|url=http://www.agilemodeling.com/essays/generalizingSpecialists.htm|publisher=Agile Modeling}}</ref> sometimes other specialists are required depending on the needs of the project. |
||
Line 132: | Line 133: | ||
* '''Independent tester'''. Although the majority of testing is done by the DAD team members, in cases with complex domains or technology an independent testing team can be brought in to work in parallel to validate the work. |
* '''Independent tester'''. Although the majority of testing is done by the DAD team members, in cases with complex domains or technology an independent testing team can be brought in to work in parallel to validate the work. |
||
* '''Integrator'''. For complex technical solutions at scale, an integrator (or multiple integrators) can be used to build the entire system from its various subsystems. |
* '''Integrator'''. For complex technical solutions at scale, an integrator (or multiple integrators) can be used to build the entire system from its various subsystems. |
||
==See also== |
|||
*[[Rational unified process]] |
|||
== References == |
== References == |
||
Line 137: | Line 141: | ||
== Further reading == |
== Further reading == |
||
* {{cite book |last1=Brown |first1=Alan |year=2012 |title=Enterprise Software Delivery: Bringing Agility and Efficiency to the Global Software Supply Chain|isbn=978- |
* {{cite book |last1=Brown |first1=Alan |year=2012 |title=Enterprise Software Delivery: Bringing Agility and Efficiency to the Global Software Supply Chain|isbn=978-0-321-80301-6}} |
||
* {{cite |
* {{cite book|last1=Royce |first1=Walker |year=2013 |title=Agility at Scale: Economic Governance, Measured Improvement and Disciplined Agile Delivery|pages=873–881 |isbn=978-1-4673-3076-3 |url=http://dl.acm.org/citation.cfm?id=2486907}} |
||
* Supporting Governance in Disciplined Agile Delivery Using Noninvasive Measurement and Process Mining, (November 2013 ''Cutter IT Journal'', Astromiskis, Janes, Sillitti, Succi) |
* Supporting Governance in Disciplined Agile Delivery Using Noninvasive Measurement and Process Mining, (November 2013 ''Cutter IT Journal'', Astromiskis, Janes, Sillitti, Succi) |
||
* 10 Principles for Success in Distributed Agile Delivery (November 2013 ''Cutter IT Journal'', Bavani) |
* 10 Principles for Success in Distributed Agile Delivery (November 2013 ''Cutter IT Journal'', Bavani) |
Latest revision as of 01:27, 24 November 2024
This article may rely excessively on sources too closely associated with the subject, potentially preventing the article from being verifiable and neutral. (November 2019) |
Part of a series on |
Software development |
---|
Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.
The primary reference for disciplined agile delivery is the book Choose Your WoW!,[1] written by Scott Ambler and Mark Lines. WoW refers to "way of working" or "ways of working".[2]
In particular, DAD has been identified as a means of moving beyond scrum.[3] According to Cutter Senior Consultant Bhuvan Unhelkar, "DAD provides a carefully constructed mechanism that not only streamlines IT work, but more importantly, enables scaling."[4] Paul Gorans and Philippe Kruchten call for more discipline in implementation of agile approaches and indicate that DAD, as an example framework, is "a hybrid agile approach to enterprise IT solution delivery that provides a solid foundation from which to scale."[5]
History
[edit]Scott Ambler and Mark Lines initially led the development of DAD, and continue to lead its evolution. DAD was developed to provide a more cohesive approach to agile software development; one that tries to fill in the process gaps that are (purposely) ignored by scrum, and one that is capable of enterprise-level scale. According to Ambler, "Many agile methodologies—including scrum, XP, AM, Agile Data, kanban , and more—focus on a subset of the activities required to deliver a solution from project initiation to delivery. Before DAD was developed, you needed to cobble together your own agile methodology to get the job done."[6]
DAD was developed as a result of observing common patterns where agility was applied at scale successfully.[7]
In 2015 the Disciplined Agile (DA) framework, later to become the Disciplined Agile Toolkit, was developed.[8] This was called Disciplined Agile 2.x. DAD formed the foundation for DA.[citation needed] A second layer, disciplined DevOps, was added as was a third layer called Disciplined Agile IT (DAIT).[citation needed] These layers, respectively, addressed how to address DevOps and IT processes in an enterprise-class setting.
Disciplined Agile 3.x was released in August 2017 to introduce a fourth layer, Disciplined Agile Enterprise (DAE), to address the full process range required for business agility.[9]
In December 2018, Disciplined Agile 4, now referred to as the Disciplined Agile Toolkit, was released.[citation needed] It focused on a completely revamped description of DAD and a team-based improvement strategy called guided continuous improvement (GCI).[citation needed]
In August 2019, Disciplined Agile was acquired by Project Management Institute.[10]
Key aspects
[edit]Many of the challenges that teams are facing are out of scope for scrum and the teams need to look to other methods with overlapping parts and conflicting terminology. DAD attempts to address these challenges by using a people-first, learning-oriented, hybrid approach to IT solution delivery.[11]
People-first
[edit]Disciplined agile delivery (DAD) identifies that "People, and the way they interact with each other, are the primary determinant of success for a solution delivery team."[12] DAD supports a robust set of roles (see below section), rights, and responsibilities that you can tailor to meet the needs of your situation. DAD promotes the ideas that team members should collaborate closely and learn from each other, that the team should invest effort to learn from their experiences and evolve their approach, and that individuals should do so as well.[13]
Hybrid
[edit]DAD is a hybrid toolkit that adopts and tailors proven strategies from existing methods such as scrum, extreme programming (XP), SAFe, agile modeling (AM), Unified Process (UP), Kanban , outside-in software development, agile data (AD) and Spotify's development model. Rather than taking the time to adapt one of these existing frameworks, with DAD all of the effort of combining relevant pieces of each technique has already been done.
Full delivery lifecycle
[edit]Unlike first generation agile methods that typically focus on the construction aspects of the lifecycle, DAD addresses the full delivery lifecycle, from team initiation all the way to delivering a solution to your end users.
Support for multiple lifecycles
[edit]DAD supports six lifecycles to choose from: agile, lean, continuous delivery, exploratory, and large-team versions of the lifecycle. DAD does not prescribe a single lifecycle because it recognizes that one approach does not fit all.
Complete
[edit]DAD shows how development, modeling, architecture, management, requirements/outcomes, documentation, governance and other strategies fit together in a streamlined whole. DAD does the "process heavy lifting" that other methods leave up to you.
Context-sensitive
[edit]The approach is goal-driven or outcome-driven rather than prescriptive. In doing so, DAD provides contextual advice regarding viable alternatives - what works, what doesn't and more importantly why - and their trade-offs, enabling you to tailor your way of working to address the situation in which you find yourself and do so in a streamlined manner.
Consumable solutions over working software
[edit]DAD matures focus from simply producing software to providing consumable solutions that provide real business value to stakeholders. While software is clearly an important part of the deliverable, being solution focused means taking a holistic view of the overall problem. This can lead to suggested updates in hardware, business and organizational processes, and overall organizational structures.
Self-organization with appropriate governance
[edit]Agile and lean teams are self-organizing, which means that the people who do the work are the ones who plan and estimate it. They must still work in an enterprise aware manner that reflects the priorities of their organization, and to do that they will need to be governed appropriately by senior leadership.
Lifecycles
[edit]Disciplined originally supported an agile (scrum-based) project lifecycle and a Lean (Kanban-based) project lifecycle. It has since been extended to support six lifecycles:
- Agile. A three-phase project lifecycle based on scrum. The phases are Inception (what is sometimes called "Sprint 0"), Construction, and Transition (what is sometimes called a Release sprint).
- Lean. A three-phase project lifecycle based on Kanban.
- Continuous delivery: Agile. An Agile-based product lifecycle that supports a continuous flow of work resulting in incremental releases (typically once a week).
- Continuous delivery: Lean. A lean-based product lifecycle that supports a continuous flow of work.
- Exploratory. An experimentation-based lifecycle based on lean startup that has been extended to address the parallel development of minimum viable products as per the advice of cynefin.
- Program. A lifecycle for coordinating a team of teams.
Process goals
[edit]DAD is described as a collection of twenty-one process goals, or process outcomes.[14] These goals guides teams through a leaner process to decisions that address the context of the situation they face. It enables teams to focus on outcomes and not on process compliance and on guesswork of extending agile methods. It enables scaling by providing sophisticated-enough strategies to address the complexities you face.
Inception phase | Construction phase | Transition phase |
---|---|---|
Get the team going in the right direction. | Incrementally build a consumable solution. | Release the solution into production. |
|
|
|
Ongoing goals | ||
Improve and work in an enterprise aware manner. | ||
|
Roles
[edit]Primary roles
[edit]These five primary roles[15] in the disciplined agile delivery are typically found regardless of scale.
- Stakeholder. Someone who is materially impacted by the outcome of the solution. More than just an end-user or customer, this is anyone potentially affected by the development and deployment of a software project.
- Product owner. The person on the team who speaks as the "one voice of the customer", representing the needs of the stakeholder community to the agile delivery team.
- Team member. The team member focuses on producing the actual solution for stakeholders, including but not limited to: testing, analysis, architecture, design, programming, planning, and estimation. They will have a subset of the overall needed skills and they will strive to gain more to become generalizing specialists.
- Team lead. The team lead is a host leader and also the agile coach, responsible for facilitating communication, empowering them to choose their way of working, and ensuring the team has the resources it needs and is free of obstacles.
- Architecture owner. Owns the architecture decisions for the team and facilitates the creation and evolution of the overall solution design.
Potential supporting roles
[edit]These supporting roles[16] are introduced (sometimes on a temporary basis) to address scaling issues.
- Specialist. Although most agile team members are generalizing specialists,[17] sometimes other specialists are required depending on the needs of the project.
- Domain expert. While the product owner represents a wide range of stakeholders, a domain expert is sometimes required for complex domains where a more nuanced understanding is required.
- Technical expert. In cases where a particularly difficult problem is encountered, a technical expert can be brought in as needed. These could be build-masters, agile database administrators, user experience (UX) designers, or security experts.
- Independent tester. Although the majority of testing is done by the DAD team members, in cases with complex domains or technology an independent testing team can be brought in to work in parallel to validate the work.
- Integrator. For complex technical solutions at scale, an integrator (or multiple integrators) can be used to build the entire system from its various subsystems.
See also
[edit]References
[edit]- ^ Ambler, Scott; Lines, Mark (2019). Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. ISBN 978-1-7904-4784-8.
- ^ Book: Choose Your WoW! – Disciplined Agile (DA)
- ^ Ambler, Scott (2013). "Going Beyond Scrum: Disciplined Agile Delivery".
- ^ Disciplined Agile Delivery in the Enterprise (Cutter IT Journal, Special Issue, June 2013)
- ^ Kruchten, Philippe; Gorans, Paul (February 2014). A Guide to Critical Success Factors in Agile Delivery (Report). IBM Center for the Business of Government. p. 14. Retrieved February 1, 2014.
a hybrid agile approach to enterprise IT solution delivery that provides a solid foundation from which to scale
- ^ Disciplined Agile Delivery Meets CMMI (Cutter IT Journal, November 2013)
- ^ "Disciplined Agile Delivery". Crosstalk. Archived from the original on 2014-02-22. Retrieved 2014-01-31.
- ^ "Intro to Disciplined Agile".
- ^ Ambler, Scott; Lines, Mark (2017). An Executive's Guide to Disciplined Agile. ISBN 978-1-5398-5296-4.
- ^ "PMI Announces Acquisition of DA".
- ^ Lines, Mark; Ambler, Scott (2019). Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. p. 41. ISBN 978-1-7904-4784-8.
- ^ Ambler, Scott. "Agility@Scale: Strategies for Scaling Agile Software Development". IBM developerWorks. IBM Software.
- ^ "Disciplined Agile Delivery: An introduction (white paper), pg 7" (PDF). IBM Software. Archived from the original (PDF) on 2013-05-29. Retrieved 2014-01-31.
- ^ Scott Ambler; Mark Lines (2019). "Choose Your WoW!". p. 46.
- ^ Ambler, Scott. "Roles on DAD Teams". disciplinedagiledelivery.com.
- ^ Ambler, Scott. "Roles on DAD Teams". disciplinedagiledelivery.com.
- ^ "Generalizing Specialists: Improving Your IT Career Skills". Agile Modeling.
Further reading
[edit]- Brown, Alan (2012). Enterprise Software Delivery: Bringing Agility and Efficiency to the Global Software Supply Chain. ISBN 978-0-321-80301-6.
- Royce, Walker (2013). Agility at Scale: Economic Governance, Measured Improvement and Disciplined Agile Delivery. pp. 873–881. ISBN 978-1-4673-3076-3.
- Supporting Governance in Disciplined Agile Delivery Using Noninvasive Measurement and Process Mining, (November 2013 Cutter IT Journal, Astromiskis, Janes, Sillitti, Succi)
- 10 Principles for Success in Distributed Agile Delivery (November 2013 Cutter IT Journal, Bavani)