Elizabeth Woodword on DAD

Elizabeth Woodward, co-author of one of my favorite books on scaling agile, A Practical Guide to Distributed Scrum, recently posted a video on Youtube entitled Disciplined Agile Delivery – The Shirt, the Summary .  I worked with Elizabeth at IBM when she led IBM’s internal agile educational support effort and actively worked with teams to help them to adopt and tailor disciplined agile strategies.  As you can read in her own book, she has deep expertise in successfully applying agile at scale.

In the video, which I had no idea that she was going to create, she shares her thoughts about why you should consider DAD.  She describes the value of the explicit inclusion of Inception activities, extending Scrum to describe a truly hybrid approach, and the explicit inclusion of transition activities.  The video is a little less than six minutes in length and I suspect you’ll find it a good use of your time.

As the title implies, she also has a few nice things to say about the “fabulous” DAD shirt we sent her.  Luckily, due to training from my wife, The Lovely Beverley, I knew enough to order a woman’s version for her.  Context counts! 

Webinar – “Disciplined Agile Delivery: Going Beyond Scrum”

Webinar – “Disciplined Agile Delivery: Going Beyond Scrum”

Join me as I introduce and moderate this presentation and discussion with Scott on 25th April at 12noon EST.

Key topics will include: 

1. What the Disciplined Agile Delivery (DAD) framework is.
2. Why a hybrid approach is necessary for enterprise development.
3. How to take a goal-driven approach (instead of prescriptive one).
4. Why a full delivery lifecycle is required and what your options actually are.
5. What complexity factors you need to consider when scaling and tailoring DAD.
6. What it means to be enterprise aware. 

Register here.

Call For Papers: Disciplined Agile Delivery for the Enterprise – Cutter IT Journal June 2013

Call for Papers: Cutter IT Journal
Guest Editor: Scott Ambler
Abstract deadline: 1 April 2013
Article deadline: 3 May 2013

Disciplined Agile Delivery in the Enterprise

Recently there have been rumblings within the industry along the lines of “what’s next after agile?” and “what does the post-agile landscape look like?” These rumblings reflect the challenges organizations face when adopting agile within an enterprise environment. Although popular, Scrum only provides a small kernel upon which to build an agile strategy, leaving you with the heavy lifting of tailoring an end-to-end agile strategy that reflects the realities of your environment. Worse yet, the simplistic strategies promoted by agile purists sow seeds of confusion and doubt amongst people still struggling to adopt an agile mindset. Beliefs that agile requires small co-located teams, downplays architecture, delivers no documentation, doesn’t work in regulatory situations, doesn’t support governance, are common. Yet those beliefs don’t reflect reality — disciplined agile teams are in fact succeeding in these situations.

Organizations that are successful at adopting and applying agile techniques effectively are going beyond Scrum and Extreme Programming (XP), and adopting a truly disciplined approach. This approach is captured in the Disciplined Agile Delivery (DAD) process decision framework. The framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven and enterprise aware, and provides a foundation from which to scale agile. DAD adopts strategies from Scrum, XP, Agile Modeling, Agile Data, Kanban, DevOps, and many more, providing advice on how to apply these techniques together in an effective manner which reflects the situation faced by the team — one process size does not fit all.

An upcoming issue of Cutter IT Journal will address the benefits, challenges and implications of adopting and applying disciplined agile strategies for enterprise software delivery.

Topics may include (but are not limited to the following) with regard to adopting a disciplined agile approach:

• How can a DAD project be successfully initiated?
• What challenges might an enterprise face in applying a DAD approach?
• What does a full agile delivery lifecycle look like in practice?
• What does it mean to apply a “hybrid agile” approach? e.g. think beyond the “Scrum+XP” box.
• In what situations would DAD not be the optimal approach to software/IT solution delivery?
• How do “enterprise aware” teams work with enterprise architects, reuse engineers, portfolio managers, and other enterprise professionals in practice?
• What cultural roadblocks might hinder the use of DAD and how can they be overcome?
• How are architecture issues addressed on a DAD project?
• How does the role of Product Owner change for large and complex agile projects?
• What roles and team structures are you actually implementing on DAD teams? Do you have business analysts, architects/architecture owners, independent testers? When do you need, or not need, such roles?
• How are you applying disciplined agile strategies to large teams/programmes?
• How are you applying disciplined agile strategies to geographically distributed teams?
• How are you applying disciplined agile strategies in regulatory compliance situations; in CMMI environments; in outsourcing/offshoring situations?

TO SUBMIT AN ARTICLE IDEA
Please respond to Scott Ambler, sambler[at]cutter[dot]com, with a copy to itjournal[at]cutter[dot]com, no later than 1 April 2013 and include an extended abstract and a short article outline showing major discussion points.

ARTICLE DEADLINE
Accepted articles are due by 1 May 2013.

EDITORIAL GUIDELINES
Most Cutter IT Journal articles are approximately 2,500-3,000 words long, plus whatever graphics are appropriate. If you have any other questions, please do not hesitate to contact CITJ’s Group Publisher, Christine Generali at cgenerali[at]cutter[dot]com or the Guest Editor, Scott Ambler, at sambler[at]cutter[dot]com. Editorial guidelines are available online

COPYRIGHT
When you submit an article to Cutter Consortium, you warrant that you (or your employer) are the sole owner of the article and that you have full power and authority to copyright it and publish it. Also, the article you submit to Cutter must be an original; not previously published elsewhere.  Articles published in the journal must meet certain criteria relating to audience, technical content, and presentation. In the unlikely occurrence that, upon selection and editorial review, your completed article does not meet with these requirements, Cutter Consortium reserves the right to decline the publishing of your article in the journal.  For more information on Cutter’s copyright policy.
AUDIENCE
Typical readers of CITJ range from CIOs and vice presidents of software organizations to IT managers, directors, project leaders, and very senior technical staff. Most work in fairly large organizations: Fortune 500 IT shops, large computer vendors, and government agencies. 48% of our readership is outside of the US (15% from Canada, 14% Europe, 5% Australia/NZ, 14% elsewhere). Please avoid introductory-level, tutorial coverage of a topic. Assume you’re writing for someone  who has been in the industry for 10 to 20 years, is very busy, and very impatient.  Assume he or she will be asking, “What’s the point? What do I do with this information?” Apply the “So what?” test to everything you write.

PROMOTIONAL OPPORTUNITIES
We are pleased to offer Journal authors a year’s complimentary subscription and five copies of the issue in which they are published. In addition, we occasionally pull excerpts, along with the author’s bio, to include in our bi-weekly Cutter Edge e-mail bulletin, which reaches another 8,000 readers. We’d also be pleased to quote you, or passages from your article, in Cutter press releases. If you plan to be speaking at industry conferences, we can arrange to make copies of your article or the entire issue available for attendees of those speaking engagements — furthering your own promotional efforts.

ABOUT CUTTER IT JOURNAL
No other journal brings together so many cutting-edge thinkers, and lets them speak so bluntly and frankly. We strive to maintain the Journal’s reputation as the “Harvard Business Review of IT.” Our goal is to present well-grounded opinion (based on real, accountable experiences), research, and animated debate about each topic the Journal explores.

Contextualization of Software Development Workshop

On Saturday, February 9 a group of people got together in Whistler British Columbia to discuss the importance of context as it pertains to software development.  The workshop was organized by the good folk at Software Development Experts (once again, thank you very much).  We shared some very important insights and had some very informative discussions.

The morning began with a kick-off from Carson Holmes.  I gave a talk summarizing the work around context frameworks, including Philippe Kruchten’s Situational Agility and the work I did at IBM around the Agile Scaling Model.  My talk summarized what we’re calling the Process Context Framework (PCF), something I will blog about soon.  Philippe then summarized his recent work on cognitive biases which explains why people, including software professionals, make suboptimal decisions and more importantly how we can avoid doing so.  Mark Kennaley overviewed the theory behind Software Development Practice Advisor and demoed some of its capabilities.  This is a product that I’ve been very interested in for some time as it’s an expert system that supports better process-oriented decisions around software development that is based on true empiricism.  Steve Adolph shared his work around how software development teams collaborate successfully, including empirical observations from is grounded-theory based work for his PHd.  Julian Holmes led us through an exercise around the contextualization of 400 agile/lean practices.  Mark and Carson ended the workshop by leading the group through a discussion of how we can work together effectively.

We had very interesting discussions throughout the day.  Disciplined Agile Delivery (DAD) was discussed at several points throughout the day.  In my presentation I briefly overviewed DAD’s goal-driven approach as I believe it is a perfect example of how to instantiate contextualization of software development.  Mark Kennaley discussed how DAD is supported as a first-class citizen in Advisor in his presentation.  For the handful of people who didn’t yet have the DAD book we gave them copies signed by Mark Lines and myself.

On Sunday many of us hit the slopes at Blackcombe/Whistler.  Below is a picture of several of us at near the top of Whistler.  More of the group went skiing than just the people appearing in the picture.

The Workshop Attendees

Back row:

• Adam Murray (A.R. Murray)
• Carson Holmes (Software Development Experts)
• Steve Adolph

Middle row:

• Sheynal Saujani (Scott Ambler + Associates)
• Doug Stewart (Blueprint)
• Mark Lines (Scott Ambler + Associates)
• Ricardo Garcia (Costco)
• Arun Zachariah (Capgemini)
• Rolf Reitzig (Ascendent Technology)
• Scott Ambler (Scott Ambler + Associates)
• Philippe Kruchten (University of British Columbia)
• Chris Armstrong (Armstrong Process Group)
• Mark Kennaley (Software Development Experts)

Front row:

• Julian Holmes (Agilementors)
• Cecile Peraire (Carnegie Mellon University)
• Geri Schneider-Winters (Wyyzzk)
• Tom Weinberger (Citicorp)
• Hadar Ziv
• Mike Bonar

IBM Rational Updates DAD Process Offerings

IBM has recently published updates to the DAD process template for IBM Rational Team Concert and their DAD process definition for IBM Rational Method Composer.

Disciplined Agilists are Enterprise Aware

Enterprise awareness is one of the key aspects of the Disciplined Agile Delivery (DAD) framework.  The observation is that DAD teams work within your organization’s enterprise ecosystem, as do all other teams.  There are often existing systems currently in production and minimally your solution shouldn’t impact them.  Better yet your solution will hopefully leverage existing functionality and data available in production.   You will often have other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa.  Your organization may be working towards business or technical visions which your team should contribute to.  A governance strategy exists which hopefully enhances what your team is doing.

What it Means to be Enterprise Aware

Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you. Teams developing in isolation may choose to build something from scratch, or use different development tools, or create different data sources, when perfectly good ones that have been successfully installed, tested, configured, and fine-tuned already exist within the organization.  Disciplined agile professionals will:

• Work closely with enterprise professionals.  This includes working closely with enterprise technical architects and reuse engineers to leverage and enhance the existing and “to be” technical infrastructure; enterprise business architects and portfolio managers to fit into the overall business ecosystem; senior managers who should be governing the various teams appropriately; operations staff to support your organization’s overall development and operations (DevOps) efforts; data administrators to access and improve existing data sources; IT development support people to understand and follow enterprise IT guidance; and business experts who share their market insights, sales forecasts, service forecasts, and other important concerns.  In other words, DAD teams should adopt what Mark refers to as a “whole enterprise” mindset.
• Adopt and follow enterprise guidance.  Your organization may have, or hopes to one day have, a range of standards and guidelines (guidance) that it wants delivery teams to adopt and follow.  This may include guidance for coding, user interface development, security, and data conventions to name a few.  Following common guidance increases the consistency and maintainability of your solutions, and thus your overall quality.
• Leverage enterprise assets. There may be many enterprise assets, or at least there should be, which you can use and evolve.  DAD teams strive to work to a common infrastructure; for example, they use the enterprise-approved technologies and data sources whenever possible, and better yet they work to the “to be” vision for your infrastructure.  If your organization uses a disciplined architecture-centric approach to building enterprise software, there will be a growing library of service-based components to reuse and improve upon for the benefit of all current and future solutions.  To do this DAD teams will collaborate with enterprise professionals throughout the lifecycle and particularly during Inception during envisioning efforts.   Figure 1 summarizes the Inception phase goal Align with Enterprise Direction which summarizes the strategies you may choose to follow.  Read Disciplined Agilists Take a Goal-Driven Approach for more information on DAD’s goal-driven strategy.

Figure 1. Inception Goal: Align with Enterprise Direction.

• Enhance your organizational ecosystem. The solution being delivered by a DAD team should minimally fit into the existing organizational ecosystem – the business processes and systems supporting them – it should better yet enhance that ecosystem.  To do this, the first step is to leverage existing enterprise assets wherever possible as described above, often working with enterprise architects to do so. In addition to the enterprise architects DAD teams will also work with operations and support staff closely throughout the lifecycle to ensure that they understand the current state and direction of the organizational ecosystem.  DAD teams will often be supported by an additional independent test team that will perform production integration testing (amongst other things) to ensure that your solution works within the target production environment which it will face at deployment time.  Furthermore, experienced DAD teams will even fix problems that they run into via proven refactoring techniques.  Figure 2 summarizes the general goal Leverage and Enhance Existing Infrastructure which summarizes strategies for how DAD teams may accomplish this.

Figure 2. General Goal: Leverage and Enhance Existing Infrastructure.

• Adopt a DevOps Culture. DAD teams will work with operations and support staff closely throughout the lifecycle, particularly the closer you get to releasing into production.  DevOps culture and strategies are baked right into DAD, a topic for a future blog posting.
• Share learnings.  DAD teams are learning oriented, and one way to learn is to hear about the experiences of others.  The implication is that DAD teams must also be prepared to share their own learnings with other teams.  To do this organizations might choose to support agile discussion forums, informal presentations, training sessions delivered by senior team members, and internal conferences to name a few strategies.
• Adopt appropriate governance strategies.  Effective governance strategies should enhance that which is being governed. An appropriate approach to governing agile delivery projects, and we suspect other types of efforts, is based on motivating and then enabling people to do what is right for your organization. What is right will of course vary, but this typically includes motivating teams to take advantage of, and to evolve, existing corporate assets following common guidelines to increase consistency, and working towards a shared vision for your organization. Appropriate governance is based on trust and collaboration. Appropriate governance strategies should enhance the ability of DAD teams to deliver business value to their stakeholders in a cost effective and timely manner.  Unfortunately many existing IT governance strategies are based on a command-and-control, bureaucratic approach which often proves ineffective in practice. The DAD book explores appropriate governance, the impact of traditional governance strategies, and how to adopt an appropriate governance strategy in detail.  The article Adopting Agile Governance Requires Discipline also provides greater insight.
• Open and honest monitoring. Although agile approaches are based on trust, smart governance strategies are based on a “trust but verify and then guide” mindset.  An important aspect of appropriate governance is the monitoring of project teams through various means.  One strategy is for anyone interested in the current status of a DAD project team to attend their daily coordination meeting and listen in, a strategy promoted by the Scrum community.  Although it’s a great strategy we highly recommend, it unfortunately doesn’t scale very well because the senior managers responsible for governance are often busy people with many efforts to govern, not just your team.  Hence the need for more sophisticated strategies such as an “development intelligence” approach supported via automated dashboards.  More on this in a future blog posting too.

Why is Enterprise Awareness Important?

Enterprise awareness is important for several reasons.  First, you can reduce overall delivery time and cost by leveraging existing assets.  In other words, DAD teams can spent less time reinventing the wheel and more time producing real value for their stakeholders.  Second, by working closely with enterprise professionals DAD teams can get going in the right direction easily.  Third, it increases the chance that your delivery team will help to optimize the organizational whole, and not just the ”solution part” that it is tasked to work on.  As the lean software development movement aptly shows this increases team effectiveness by reducing time to market.

Challenges to Enterprise Awareness

Unfortunately there are two main challenges to supporting enterprise awareness on agile teams.  First is the cultural challenge within the agile community that some ”agile purists” perceive this as unecessary overhead.  Reasons for this misunderstanding include a lack of understanding of the overall enterprise picture or some agilists who have previous experiences with enterprise professionals who struggle to work in an agile manner.  This points to the second challenge that enterprise professionals often don’t understand how to work effectively with agile teams.  Sometimes this is because the agile teams they’ve been working with until now haven’t been sufficiently disciplined to work with them effectively, but more often than not it’s because they still choose to follow older, more traditional approaches to their craft (they may find my articles about Agile Enterprise Architecture, Agile Enterprise Administration, and even The Enterprise Unified Process to be illuminating).

These challenges are cultural in nature, and thus difficult to overcome.  Agilists and enterprise professionals need to respect one another and strive to learn more about what the other group is trying to accomplish.  They must strive to work with one another and thus learn from each other.  Not only is this possible it is highly desirable.

In summary, DAD teams and more importantly DAD practitioners are enterprise aware.  They recognize that enterprise aware strategies improve their ability to provide value to their stakeholders both within the scope of a solution as well as at the organizational level.  To coin an environmental cliché: Disciplined agilists act locally and think globally.

Material for this blog posting was modified from Discplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler and Mark Lines (IBM Press, 2012)

2012 in review

This has been a very active website in 2012.  Thank you all for your interest and participation.  We are looking forward to some great discussions again this year.

Mark & Scott

Here’s an excerpt:

4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 36,000 views in 2012. If each view were a film, this blog would power 8 Film Festivals

Click here to see the complete report.

Roles in Disciplined Agile Delivery

The Disciplined Agile Delivery (DAD) framework suggests a robust set of roles for agile solution delivery.  These roles are overviewed in the following figure:

Primary Roles

Primary roles are commonly found regardless of the level of scale.  There are five primary roles:

1. Stakeholder.  A stakeholder is someone who is materially impacted by the outcome of the solution.  In this regard, the stakeholder is clearly more than an end-user: A stakeholder could be a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, maintenance professionals potentially affected by the development and/or deployment of a software project.   DAD teams will ideally work together with their stakeholders daily throughout the project.
2. Team Member.  The role of team member focuses on producing the actual solution for stakeholders.  Team members will perform testing, analysis, architecture, design, programming, planning, estimation, and many more activities as appropriate throughout the project.  Note that not every team member will have every single one of these skills, at least not yet, but they will have a subset of them and they will strive to gain more skills over time.  Team members are sometimes described by core agile methods as “developers” or simply as programmers.  However, in DAD we recognize that not every team member necessarily writes code.   Team members will identify tasks, estimate tasks, “sign-up” for tasks, perform the tasks, and track their status towards completion.
3. Team Lead.  On agile projects the role of the traditional project manager changes substantially, and in fact the term project manager is now unfortunately frowned upon.  The agile community has focused on project or team leadership over team management, observing that the best “managers” prioritize leadership over technical management issues such as planning and estimation.  An important aspect of self-organizing teams is that the team lead facilitates or guides the team in performing technical management activities instead of taking on these responsibilities him or herself.  The team lead is a servant-leader to the team, creating and maintaining the conditions that allow the team to be successful.  The team lead is also an agile coach, helping to keep the team focused on delivering work items and fulfilling their iteration goals and commitments that they have made to the product owner.  He or she acts as a true leader, facilitating communication, empowering them to self-optimize their processes, ensuring that the team has the resources that it needs, and removes any impediments to the team (issue resolution) in a timely manner.  When teams are self organizing, effective leadership is crucial to your success.
4. Product Owner.  In a system with hundreds or thousands of requirements it is often difficult to get answers to questions regarding the requirements.  The product owner is the one individual on the team who speaks as the “one voice of the customer”.  He or she represents the needs and desires of the stakeholder community to the agile delivery team.  As such, he or she clarifies any details regarding the solution and is also responsible for maintaining a prioritized list of work items that the team will implement to deliver the solution.  While the product owner may not be able to answer all questions, it is their responsibility to track down the answer in a timely manner so that the team can stay focused on their tasks.  Having a product owner working closely with the team to answer any question about work items as they are being implemented substantially reduces the need for requirements, testing, and design documentation.  You will of course still have need for deliverable documentation such as operations manuals, support  manuals, and user guides to name a few. Each DAD team, or subteam in the case of large programmes organized into a team of teams, has a single product owner.  A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community.  This includes arranging demonstrations of the solution as it evolves and communicating project status to key stakeholders.
5. Architecture Owner.  Architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk.  As a result the DAD framework explicitly includes Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design. The person in the role of team lead will often also be in the role of architecture owner on small teams.  This isn’t always the case, particularly at scale, but it is very common for smaller agile teams.  Although the architecture owner is typically the senior developer on the team – and sometimes may be known as the technical architect, software architect, or solution architect – it should be noted that this is not a hierarchical position into which other team members report.  He or she is just like any other team member and is expected to sign-up and deliver work related to tasks like any other team member.  Architecture owners should have a technical background and a solid understanding of the business domain.

Secondary Roles

Secondary roles are typically introduced, often on a temporary basis, to address scaling issues.  There are five secondary roles:

1. Specialist.  Although most agile team members are generalizing specialists, sometimes, particularly at scale, specialists are required.  For example, on large teams or in complex domains one or more agile business analysts may join the team to help you to explore the requirements for what you’re building.  On very large teams a program manager may be required to coordinate the team leads on various subteams.  You will also see specialists on DAD teams when generalizing specialists aren’t available – when your organization is new to agile it may be staffed primarily with specialists who haven’t yet made the transition to generalizing specialists.
2. Domain Expert.  The product owner represents a wide range of stakeholders, not just end users, so it isn’t reasonable to expect them to be experts in every nuance in your domain, something that is particularly true with complex domains. The product owner will sometimes bring in domain experts to work with the team, for example, a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision for the project.
3. Technical Expert.  Sometimes the team needs the help of technical experts, such as a build master to set up their build scripts, an agile database administrator to help design and test their database, a user experience (UX) expert to help design a usable interface, or a security expert to provide advice around writing a secure system. Technical experts are brought in on an as-needed, temporary basis to help the team overcome a difficult problem and to transfer their skills to one or more developers on the team.  Technical experts are often working on other teams that are responsible for enterprise-level technical concerns or are simply specialists on loan to your team from other delivery teams.
4. Independent Tester.Although the majority of the testing is done by the people on the DAD team themselves, some DAD teams are supported by an independent test team working in parallel that validates their work throughout the lifecycle.  This independent test team is typically needed for agility at scale situations within complex domains, using complex technology, or addressing regulatory compliance issues.
5. Integrator.For large DAD teams which have been organized into a team of subteams, the subteams are typically responsible for one or more subsystems or features. The larger the overall team, generally the larger and more complicated the system being built. In these situations, the overall team may require one or more people in the role of integrator responsible for building the entire system from its various subsystems.  On smaller teams or in simpler situations the Architecture Owner is typically responsible for ensuing integration, a responsibility that is picked up by the integrator(s) for more complex environments.  Integrators often work closely with the independent test team, if there is one, to perform system integration testing regularly throughout the project.  This integrator role is typically only needed at scale for complex technical solutions.

Why So Many Roles?

This is a common question that we get from people familiar with Scrum.  Scrum has three roles – ScrumMaster, Product Owner, and Team Member - so why does DAD need ten?  The primary issue is one of scope.  Scrum mostly focuses on leadership and change management aspects during Construction and therefore has roles which reflect this.  DAD on the other hand explicitly focuses on the entire delivery lifecycle and all aspects of solution delivery, including the technical aspects that Scrum leaves out.  So, with a larger scope comes more roles.  For example, because DAD encompasses agile architecture issues it includes an Architecture Owner role.  Scrum doesn’t address architecture so doesn’t include such a role.

Some Important Thoughts About Roles

On a DAD project any given person will be in one or more roles, an individual can change their role(s) over time, and any given role will have zero or more people performing it at any given time.  For example, Peter may be in the role of team member and architecture owner right now but step into the role of team lead next month when Carol, the existing team lead, goes on vacation.

Roles are not positions, nor are they meant to be.  For example, Jane may be in the role of stakeholder for your project but have the position of Chief Financial Officer (CFO) within your organization. In fact, although there may be hundreds of stakeholders of your project none of them is likely to have a position of “stakeholder.”

Agile deemphasizes specialized roles and considers all team members equal – everyone pitches in to deliver a working solution regardless of their job description. An implication of this is that with the exception of stakeholder everyone is effectively in the role of team member.

Traditional roles, such as business analyst and project manager, do not appear in DAD.  The goals which people in traditional roles try to achieve, for example in the case of a business analyst to understand and communicate the stakeholder needs/intent for the solution, are still addressed in DAD but in different ways by different roles.  There isn’t a perfect one-to-one match between any given traditional role and a DAD role, but as you will find in the Disciplined Agile Delivery book there are reasonable transition strategies.  The critical thing for traditionalists to understand is that because the underlying paradigm and strategy has changed, they too must change to reflect the DAD approach.

Material for this blog posting was modified from Chapter 4 of Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (IBM Press, 2012)