AgileCamp 2014 Track 1: Scaling agile with Disciplined Agile Delivery

Editor's Notes

• #4: Both an agile mindset and agile ways of working together
• #5: Doing agile at scale or applying agile to solution delivery at scale in the face of such complicating factors asTeam Size - 2 to 1000sGeographic Distribution - Co-located to GlobalOrganizational Distribution - Single Division to OutsourcingCompliance - None to Life CriticalDomain Complexity - Straightforward to Very ComplexTechnical Complexity - Straightforward to Very Complex
• #6: Hard to get everyone thinking and behaving in an agile way when you haven’t figured out how to achieve large-scale agile solution deliveryRecap 1) agile mindset and agile practices across entire organization, and 2) doing agile at scale, in the face of scaling factors
• #7: Can you stay nimble and lightweight and be big?Before we talk about the strategies DAD suggests, you should first test the assumption that you should be doing large-scale Agile in the first place. Why are you scaling? Do you have to work with a large, globally distributed team? Why can’t you have a small, co-located team? Just because you can scale Agile doesn’t mean you should. If you layer in strategies that end up maintaining the status quo, then why put in all the effort to do it?Large-scale Agile adds potential complexity and overhead that can slow you down and make you less agile. So is it then worth it?
• #10: It is clear that many common agile practices require discipline. For example, agile teams it takes discipline to hold concise, streamlined coordination/Scrum meetings; to consistently deliver business value every iteration; to test continuously throughout the lifecycle; to improve your process “in flight”; to work closely with stakeholders and many more things. Discipline is very important to the success of agile teams, see The Discipline of Agile for a detailed discussion, and DAD takes it to the next level in the following ways:Reducing the feedback cycle. Techniques that shorten the time between doing something and getting feedback about it are generally lower risk and result in lower cost to address any changes than techniques with longer feedback cycles. Many of these techniques require agile team members to have new skills and to take a more disciplined approach to their work than they may have in less-than-agile situations. There are several common ways to shorten the feedback cycle that are common to agile software development that are adopted by the DAD framework. These techniques, listed in order of immediacy, include non-solo development (e.g. pair programming), active stakeholder participation, continuous integration (CI), continuous deployment (CD), short iterations/sprints, and short release cycles.Continuous learning. Continuous learning is an important aspect of agile software development in general, not just DAD. However, DAD explicitly addresses the need for three levels of learning: individual, team, and organizational/enterprise. It also addresses the need for three categories of learning: domain, technical, and process. Continuous learning strategies include active stakeholder participation, coaching, mentoring, individual learning, non-solo development, proving the architecture with working code, spikes, retrospectives/reflections, sharing lessons learned between teams, and stakeholder demonstrations.Incremental delivery of consumable solutions. Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline. The DAD process framework goes one step further and advises you to explicitly produce a potentially consumable solution every iteration, something that requires even greater discipline. Every construction iteration your team requires the discipline to create working software that is “done”, to write deliverable documentation such as operations manuals and user documentation, to address consumability (usability), to consider organizational change issues pertaining to your solution, and operations and support issues (an aspect of DevOps).Being process goal-driven. The DAD framework promotes a process goal-driven approach. For each goal we describe the issues pertaining to that the goal. For example, with initial project planning you need to consider issues such as the amount of initial detail you intend to capture, the amount of ongoing detail throughout the project, the length of iterations, how you will communicate the schedule (if at all), and how you will produce an initial cost estimate (if at all). Each issue can be addressed by several strategies, each of which has trade-offs. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves in. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy which that is most appropriate for them.Enterprise awareness. Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you need to act accordingly. It takes discipline to be enterprise aware and to work with enterprise folks who may not be completely agile yet, and have the patience to help them. It takes discipline to work with your operations and support staff in a “DevOps” manner throughout the lifecycle, particularly when they may not be motivated to do so. Despite the fact that governing bodies such as project management offices (PMOs), architecture and database authorities, and operations may indeed be a source of impediments to your DAD adoption, these authorities serve important functions in any large enterprise. Therefore a disciplined approach to proactively working with them and being a positive change agent to make collaboration with them more effective is required.Adopting a full delivery lifecycle. Despite some agilists reluctance to admit that projects go through phases the DAD process framework explicitly recognizes that they do. Building serious solutions requires a lot more than just doing the cool construction stuff. It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle. The basic and advanced DAD lifecycles explicitly depict pre-delivery activities, a three-phase delivery lifecycle, and post-delivery activities (operations and support).Streamlining inception activities. We devoted a lot of material in the DAD book to describing how to effectively address how to initiate a DAD project. Unfortunately in our experience we have seen many organizations treat this phase as an opportunity to do massive amounts of upfront documentation in the form of project plans, charters, and requirements specifications. Some people have referred to the practice of doing too much transitory documentation up front on an agile project (known as Sprint 0 in Scrum) as Water-Scrum-Fall. We cannot stress enough that this is NOT the intent of the Inception phase. While we provide many alternatives for documenting your vision in Inception, from very heavy to very light, you should take a minimalist approach to the Inception phase and strive to reach the stakeholder consensus milestone as quickly as possible. If you are spending more than a few weeks on this phase, you may be regressing to a Water-Scrum-Fall approach. It takes discipline to be aware of this trap and to streamline your approach as much as possible.Streamlining transition activities. In most mid-to-large sized organizations the deployment of solutions is carefully controlled, particularly when the solutions share architectures and have project interdependencies. For these reasons release cycles to your stakeholders are less frequent that you would like because of existing complexities within the environment. However, the ability to frequently deploy value to your stakeholders is a competitive advantage; therefore you should reduce the release cycle as much as possible. This requires a great degree of discipline in areas such as pre-production integration and deployment testing; regular coordination between project teams and with operations and support staff; Change management around both technology and requirements; and adoption of continuous deployment practices to such a degree that very frequent deployments are the norm and the Transition “phase” becomes an automated transition activity.Adopting agile governance. It is easier to avoid your traditional governance and tell management that “agile is different” than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams. Every organization has a necessary degree of governance and there are ways to make it especially effective on agile initiatives. It takes discipline to work with your governors to help them understand how disciplined agile teams operate and then discipline to accept and conform to the resulting governance process.Moving to lean. For all DAD process goals we describe a range of options to address the issues pertaining to that goal. These options ranged from traditional/heavier approaches that we generally advised against except in very specific situations to agile strategies to very lean strategies. Generally, the leaner the strategy the greater the discipline it requires.
• #11: It is clear that many common agile practices require discipline. For example, agile teams it takes discipline to hold concise, streamlined coordination/Scrum meetings; to consistently deliver business value every iteration; to test continuously throughout the lifecycle; to improve your process “in flight”; to work closely with stakeholders and many more things. Discipline is very important to the success of agile teams, see The Discipline of Agile for a detailed discussion, and DAD takes it to the next level in the following ways:Reducing the feedback cycle. Techniques that shorten the time between doing something and getting feedback about it are generally lower risk and result in lower cost to address any changes than techniques with longer feedback cycles. Many of these techniques require agile team members to have new skills and to take a more disciplined approach to their work than they may have in less-than-agile situations. There are several common ways to shorten the feedback cycle that are common to agile software development that are adopted by the DAD framework. These techniques, listed in order of immediacy, include non-solo development (e.g. pair programming), active stakeholder participation, continuous integration (CI), continuous deployment (CD), short iterations/sprints, and short release cycles.Continuous learning. Continuous learning is an important aspect of agile software development in general, not just DAD. However, DAD explicitly addresses the need for three levels of learning: individual, team, and organizational/enterprise. It also addresses the need for three categories of learning: domain, technical, and process. Continuous learning strategies include active stakeholder participation, coaching, mentoring, individual learning, non-solo development, proving the architecture with working code, spikes, retrospectives/reflections, sharing lessons learned between teams, and stakeholder demonstrations.Incremental delivery of consumable solutions. Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline. The DAD process framework goes one step further and advises you to explicitly produce a potentially consumable solution every iteration, something that requires even greater discipline. Every construction iteration your team requires the discipline to create working software that is “done”, to write deliverable documentation such as operations manuals and user documentation, to address consumability (usability), to consider organizational change issues pertaining to your solution, and operations and support issues (an aspect of DevOps).Being process goal-driven. The DAD framework promotes a process goal-driven approach. For each goal we describe the issues pertaining to that the goal. For example, with initial project planning you need to consider issues such as the amount of initial detail you intend to capture, the amount of ongoing detail throughout the project, the length of iterations, how you will communicate the schedule (if at all), and how you will produce an initial cost estimate (if at all). Each issue can be addressed by several strategies, each of which has trade-offs. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves in. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy which that is most appropriate for them.Enterprise awareness. Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you need to act accordingly. It takes discipline to be enterprise aware and to work with enterprise folks who may not be completely agile yet, and have the patience to help them. It takes discipline to work with your operations and support staff in a “DevOps” manner throughout the lifecycle, particularly when they may not be motivated to do so. Despite the fact that governing bodies such as project management offices (PMOs), architecture and database authorities, and operations may indeed be a source of impediments to your DAD adoption, these authorities serve important functions in any large enterprise. Therefore a disciplined approach to proactively working with them and being a positive change agent to make collaboration with them more effective is required.Adopting a full delivery lifecycle. Despite some agilists reluctance to admit that projects go through phases the DAD process framework explicitly recognizes that they do. Building serious solutions requires a lot more than just doing the cool construction stuff. It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle. The basic and advanced DAD lifecycles explicitly depict pre-delivery activities, a three-phase delivery lifecycle, and post-delivery activities (operations and support).Streamlining inception activities. We devoted a lot of material in the DAD book to describing how to effectively address how to initiate a DAD project. Unfortunately in our experience we have seen many organizations treat this phase as an opportunity to do massive amounts of upfront documentation in the form of project plans, charters, and requirements specifications. Some people have referred to the practice of doing too much transitory documentation up front on an agile project (known as Sprint 0 in Scrum) as Water-Scrum-Fall. We cannot stress enough that this is NOT the intent of the Inception phase. While we provide many alternatives for documenting your vision in Inception, from very heavy to very light, you should take a minimalist approach to the Inception phase and strive to reach the stakeholder consensus milestone as quickly as possible. If you are spending more than a few weeks on this phase, you may be regressing to a Water-Scrum-Fall approach. It takes discipline to be aware of this trap and to streamline your approach as much as possible.Streamlining transition activities. In most mid-to-large sized organizations the deployment of solutions is carefully controlled, particularly when the solutions share architectures and have project interdependencies. For these reasons release cycles to your stakeholders are less frequent that you would like because of existing complexities within the environment. However, the ability to frequently deploy value to your stakeholders is a competitive advantage; therefore you should reduce the release cycle as much as possible. This requires a great degree of discipline in areas such as pre-production integration and deployment testing; regular coordination between project teams and with operations and support staff; Change management around both technology and requirements; and adoption of continuous deployment practices to such a degree that very frequent deployments are the norm and the Transition “phase” becomes an automated transition activity.Adopting agile governance. It is easier to avoid your traditional governance and tell management that “agile is different” than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams. Every organization has a necessary degree of governance and there are ways to make it especially effective on agile initiatives. It takes discipline to work with your governors to help them understand how disciplined agile teams operate and then discipline to accept and conform to the resulting governance process.Moving to lean. For all DAD process goals we describe a range of options to address the issues pertaining to that goal. These options ranged from traditional/heavier approaches that we generally advised against except in very specific situations to agile strategies to very lean strategies. Generally, the leaner the strategy the greater the discipline it requires.
• #12: It is clear that many common agile practices require discipline. For example, agile teams it takes discipline to hold concise, streamlined coordination/Scrum meetings; to consistently deliver business value every iteration; to test continuously throughout the lifecycle; to improve your process “in flight”; to work closely with stakeholders and many more things. Discipline is very important to the success of agile teams, see The Discipline of Agile for a detailed discussion, and DAD takes it to the next level in the following ways:Reducing the feedback cycle. Techniques that shorten the time between doing something and getting feedback about it are generally lower risk and result in lower cost to address any changes than techniques with longer feedback cycles. Many of these techniques require agile team members to have new skills and to take a more disciplined approach to their work than they may have in less-than-agile situations. There are several common ways to shorten the feedback cycle that are common to agile software development that are adopted by the DAD framework. These techniques, listed in order of immediacy, include non-solo development (e.g. pair programming), active stakeholder participation, continuous integration (CI), continuous deployment (CD), short iterations/sprints, and short release cycles.Continuous learning. Continuous learning is an important aspect of agile software development in general, not just DAD. However, DAD explicitly addresses the need for three levels of learning: individual, team, and organizational/enterprise. It also addresses the need for three categories of learning: domain, technical, and process. Continuous learning strategies include active stakeholder participation, coaching, mentoring, individual learning, non-solo development, proving the architecture with working code, spikes, retrospectives/reflections, sharing lessons learned between teams, and stakeholder demonstrations.Incremental delivery of consumable solutions. Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline. The DAD process framework goes one step further and advises you to explicitly produce a potentially consumable solution every iteration, something that requires even greater discipline. Every construction iteration your team requires the discipline to create working software that is “done”, to write deliverable documentation such as operations manuals and user documentation, to address consumability (usability), to consider organizational change issues pertaining to your solution, and operations and support issues (an aspect of DevOps).Being process goal-driven. The DAD framework promotes a process goal-driven approach. For each goal we describe the issues pertaining to that the goal. For example, with initial project planning you need to consider issues such as the amount of initial detail you intend to capture, the amount of ongoing detail throughout the project, the length of iterations, how you will communicate the schedule (if at all), and how you will produce an initial cost estimate (if at all). Each issue can be addressed by several strategies, each of which has trade-offs. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves in. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy which that is most appropriate for them.Enterprise awareness. Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you need to act accordingly. It takes discipline to be enterprise aware and to work with enterprise folks who may not be completely agile yet, and have the patience to help them. It takes discipline to work with your operations and support staff in a “DevOps” manner throughout the lifecycle, particularly when they may not be motivated to do so. Despite the fact that governing bodies such as project management offices (PMOs), architecture and database authorities, and operations may indeed be a source of impediments to your DAD adoption, these authorities serve important functions in any large enterprise. Therefore a disciplined approach to proactively working with them and being a positive change agent to make collaboration with them more effective is required.Adopting a full delivery lifecycle. Despite some agilists reluctance to admit that projects go through phases the DAD process framework explicitly recognizes that they do. Building serious solutions requires a lot more than just doing the cool construction stuff. It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle. The basic and advanced DAD lifecycles explicitly depict pre-delivery activities, a three-phase delivery lifecycle, and post-delivery activities (operations and support).Streamlining inception activities. We devoted a lot of material in the DAD book to describing how to effectively address how to initiate a DAD project. Unfortunately in our experience we have seen many organizations treat this phase as an opportunity to do massive amounts of upfront documentation in the form of project plans, charters, and requirements specifications. Some people have referred to the practice of doing too much transitory documentation up front on an agile project (known as Sprint 0 in Scrum) as Water-Scrum-Fall. We cannot stress enough that this is NOT the intent of the Inception phase. While we provide many alternatives for documenting your vision in Inception, from very heavy to very light, you should take a minimalist approach to the Inception phase and strive to reach the stakeholder consensus milestone as quickly as possible. If you are spending more than a few weeks on this phase, you may be regressing to a Water-Scrum-Fall approach. It takes discipline to be aware of this trap and to streamline your approach as much as possible.Streamlining transition activities. In most mid-to-large sized organizations the deployment of solutions is carefully controlled, particularly when the solutions share architectures and have project interdependencies. For these reasons release cycles to your stakeholders are less frequent that you would like because of existing complexities within the environment. However, the ability to frequently deploy value to your stakeholders is a competitive advantage; therefore you should reduce the release cycle as much as possible. This requires a great degree of discipline in areas such as pre-production integration and deployment testing; regular coordination between project teams and with operations and support staff; Change management around both technology and requirements; and adoption of continuous deployment practices to such a degree that very frequent deployments are the norm and the Transition “phase” becomes an automated transition activity.Adopting agile governance. It is easier to avoid your traditional governance and tell management that “agile is different” than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams. Every organization has a necessary degree of governance and there are ways to make it especially effective on agile initiatives. It takes discipline to work with your governors to help them understand how disciplined agile teams operate and then discipline to accept and conform to the resulting governance process.Moving to lean. For all DAD process goals we describe a range of options to address the issues pertaining to that goal. These options ranged from traditional/heavier approaches that we generally advised against except in very specific situations to agile strategies to very lean strategies. Generally, the leaner the strategy the greater the discipline it requires.
• #13: The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.”Many organizations start their agile journey by adopting Scrum because it describes a good strategy for leading agile software teams. However, Scrum is only part of what is required to deliver sophisticated solutions to your stakeholders. Invariably teams need to look to other methods to fill in the process gaps that Scrum purposely ignores. When looking at other methods there is considerable overlap and conflicting terminology that can be confusing to practitioners as well as outside stakeholders. Worse yet people don’t always know where to look for advice or even know what issues they need to consider. To address these challenges the Disciplined Agile Delivery (DAD) process decision framework provides a more cohesive approach to agile solution delivery. There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users. It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.For more information, visit http://DisciplinedAgileDelivery.com
• #14: To understand the need for the Disciplined Agile Delivery (DAD) process framework you must start by recognizing the realities of the situation which you face. The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum. We felt that the first step was to identify how to successfully develop a solution from end-to-end. Although mainstream agile methods clearly provided a lot of great strategies, there really wasn’t any sort of way to put it all together beyond hiring a consultant and getting their advice. This is where the DAD framework comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself.The DAD framework provides a better foundation for scaling agile:Risk and value driven lifecycle. Scrum has what is called a value driven lifecycle. Work is prioritized by value to the business and is performed in priority order. This is a pretty good approach, but it’s possible to do better. Disciplined agile teams recognize that it’s a pretty good idea to tackle the riskier work early in an endeavor in order to help eliminate some or all of the risk. Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of succeeding early. A risk-value approach to work prioritization, and better yet explicit risk-based milestones (such as reaching stakeholder agreement early and proving the architecture with working code early), can increase your chance of project success.Self organization with effective governance. There has been much ado made over the strategy of self organizing teams with the agile community and rightfully so as it is an effective strategy. But, agile project teams don’t work in a vacuum but instead work within the scope and constraints of a larger, organizational ecosystem. Instead of optimizing the project part as many agile methods imply that you should do in DAD we recommend that you adopt an effective governance strategy that guides and enables agile teams.Delivery of consumable solutions over construction of working software. There are two issues here, a delivery focus over a construction focus and a solution focus over a software focus. First, disciplined agile teams recognize that there is some up-front project initiation/inception work that occurs early in a project. DAD also recognizes that there is often some deployment/transition effort that occurs towards the end of a project. The end result is that DAD promotes the idea that you need to adopt a full delivery lifecycle, not just a construction-focused lifecycle, if you’re to successfully avoid common mistakes such as a Water-Scrum-Fall approach. Futhermore, because DAD isn’t prescriptive it suggests several versions (agile, lean, continuous delivery) of the lifecycle. Second, agile teams do far more than produce software. We create supporting documentation. The software runs on hardware that may need to be upgraded and/or redeployed. We potentially change the business process around the usage of the system we’re producing. We may even affect changes to the organization structure of the people using the system. In short, it is blatantly obvious that we’re not just producing “potentially shippable software” but instead are producing “potentially shippable solutions”. Moreover, producing something that is just “potentially shippable” isn’t what our stakeholders actually want. What they really desire is something that’s consumable, something that they can easily understand and adopt to help them achieve their goals. The rhetoric “potentially shippable software” plays well to some developers, but it isn’t a sufficient goal.Enterprise awareness over team awareness. We alluded to this in point #2. Disciplined agile teams recognize that they work in a larger organizational ecosystem. This enterprise awareness motivates them to leverage existing assets; enhance existing assets; work closely with enterprise professionals such as enterprise architects, reuse engineers, portfolio managers, and data adminstrators; and produce solutions that reflect the technology and business roadmaps of your organization. Done right this increases a team’s ability to deliver.Context-sensitive and goal driven over prescriptive. One process size does not fit all. A strategy that works for a small co-located team will put a large geographically distributed team at risk. A strategy that works well in a non-regulatory environment may result in people’s deaths in a regulatory one (or more likely fines because hopefully you’ll be caught before you ship). So, if you want to build an effective team you need to be able to select the right strategy for the situation you find yourself in. DAD describes a straightforward, easy to consume strategy that is goal driven
• #15: Where do all of these strategies come from?DAD leverages proven strategies from agile, lean, iterative, and even traditional sources, providing a decision framework to guide your adoption and tailoring of them according to your context.
• #17: All of this goes into the work of the teamThis is all captured in the work item list
• #18: All of this goes into the work of the teamThis is all captured in the work item list
• #19: All of this goes into the work of the teamThis is all captured in the work item list
• #20: When you focus on solutions, not just software, you realize you might also need more rolesDAD helps you figure out what roles you might need and how they can help your organization provide agile delivery of solutionsTeam LeadAgile process expert, keeps team focused on achievement of goals, removes impedimentsProduct OwnerOwns the product vision, scope and priorities of the solutionArchitecture OwnerOwns the architecture decisions and technical priorities, mitigates key technical risksTeam MemberCross-functional team members that deliver the solutionStakeholderIncludes the customer but also other stakeholders such as Project Sponsor, DevOps, architecture, database groups, governance bodiesPrimary roles are commonly found regardless of the level of scale. Secondary roles are typically introduced, often on a temporary basis, to address scaling issues. 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 AOrole. Scrum doesn’t address architecture so doesn’t include such a role.Some Important Thoughts About RolesOn 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.
• #21: All of this goes into the work of the teamThis is all captured in the work item list
• #22: There’s more to IT solution delivery than building stuff. (aka “construction”)But there’s work that goes into preparing for a projectAnd there’s work that gets done at the end of the project as you release to production and wind things downScrum emphasizes product development, which is great if your focus is developing products…--------------------------------------------------------------------------One of the key aspects of the Disciplined Agile Delivery (DAD) process decision framework is that it promotes a full, end-to-end, solution delivery lifecycle. The figure on this slide overviews a high-level view of the DAD lifecycle. It is a three-phase lifecycle, more on this in a minute, where you incrementally build a consumable solution over time. We start with this high-level view so that we can explore several important concepts before diving into details.First, the DAD lifecycle explicitly calls out three phases:Inception. During this phase project initiation activities occur. Although “phase” tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project. While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2013 Agile Initiation survey, http://Ambysoft.com/surveys/, found the average agile team spends about a month in Inception whereas the most common iteration/sprint length is two weeks). So in DAD’s Inception phase we do some very lightweight visioning activities to properly frame the project. It takes discipline to keep Inception short.Construction. During this phase a DAD team will produce a potentially consumable solution on an incremental basis. They may do so via a set of iterations (Sprints in Scrum parlance) or do so via a lean, continuous flow approach (different versions of the lifecycle are discussed later). The team applies a hybrid of practices from Scrum, XP, Agile Modeling, Agile Data, and other methods to deliver the solution.Transition. DAD recognizes that for sophisticated enterprise agile projects deploying the solution to the stakeholders is often not a trivial exercise. DAD teams, as well as the enterprise overall, will streamline their deployment processes so that over time this phase become shorters and ideally disappears from adopting continuous deployment strategies. It takes discipline to evolve Transition from a phase to an activity.
• #23: There’s more to IT solution delivery than building stuff. (aka “construction”)But there’s work that goes into preparing for a projectAnd there’s work that gets done at the end of the project as you release to production and wind things downScrum emphasizes product development, which is great if your focus is developing products…--------------------------------------------------------------------------One of the key aspects of the Disciplined Agile Delivery (DAD) process decision framework is that it promotes a full, end-to-end, solution delivery lifecycle. The figure on this slide overviews a high-level view of the DAD lifecycle. It is a three-phase lifecycle, more on this in a minute, where you incrementally build a consumable solution over time. We start with this high-level view so that we can explore several important concepts before diving into details.First, the DAD lifecycle explicitly calls out three phases:Inception. During this phase project initiation activities occur. Although “phase” tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project. While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2013 Agile Initiation survey, http://Ambysoft.com/surveys/, found the average agile team spends about a month in Inception whereas the most common iteration/sprint length is two weeks). So in DAD’s Inception phase we do some very lightweight visioning activities to properly frame the project. It takes discipline to keep Inception short.Construction. During this phase a DAD team will produce a potentially consumable solution on an incremental basis. They may do so via a set of iterations (Sprints in Scrum parlance) or do so via a lean, continuous flow approach (different versions of the lifecycle are discussed later). The team applies a hybrid of practices from Scrum, XP, Agile Modeling, Agile Data, and other methods to deliver the solution.Transition. DAD recognizes that for sophisticated enterprise agile projects deploying the solution to the stakeholders is often not a trivial exercise. DAD teams, as well as the enterprise overall, will streamline their deployment processes so that over time this phase become shorters and ideally disappears from adopting continuous deployment strategies. It takes discipline to evolve Transition from a phase to an activity.
• #24: Why do you stand up at your Daily Scrum?Why do you even have daily stand-ups?What is the goal behind this specific process? To coordinate your work. Not “because Scrum says so…”
• #25: This goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods. For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD also indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.First and foremost, DAD is a process decision framework. One what that it achieves this through it’s goal-driven approach that guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face. There are several fundamental advantages to taking a goal driven approach to agile solution delivery. A goal-driven approach:Supports process tailoring. Goal diagram, visit http://DisciplinedAgileDelivery.com for examples, make it very clear how DAD enables people to make intelligent process decisions. Enables effective scaling. DAD provides a foundation from which to scale agile approaches. An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face. For example, consider your approach to exploring the initial scope of your effort. A large team or a geographically distributed team will make different tailoring decisions than a small co-located team. A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments. These are just three of several scaling factors.Makes your process options very clear. The more detailed goals diagrams make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team.Takes the guesswork out of extending agile methods. Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs. Yes, we suppose this claim is true but how do you do so? Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the framework cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues? In short, shouldn’t it be a hybrid? Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here?Makes it clear what risks you’re taking on. By making your process decision options clear, and by describing the trade-offs associated with those options, DAD makes it very clear what risks you’re taking on. Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DAD is going to make it very clear what risks you’ve just taken on by doing so. DAD also makes it clear when this decision is appropriate, so if you’re not in this situation then it is likely time to rethink your approach. Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach. Since the DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects. In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakholder value and here’s why” will be listened to.It hints at an agile maturity model. Scott wrote an article for the December 2012 Cutter IT Journal issue about how DAD and CMMI potentially fit together (DAC members may download this from http://DisciplinedAgileConsortium.org). In that article he suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication. Having said that we have no desire to wade into the agile maturity model morass, but we think it’s an important observation nonetheless.So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations. First, it makes the complexities of solution delivery explicit. Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice. Second, some people just want to be told what to do and actually prefer a prescriptive approach. DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people. Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods.
• #26: This goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods. For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD also indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.First and foremost, DAD is a process decision framework. One what that it achieves this through it’s goal-driven approach that guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face. There are several fundamental advantages to taking a goal driven approach to agile solution delivery. A goal-driven approach:Supports process tailoring. Goal diagram, visit http://DisciplinedAgileDelivery.com for examples, make it very clear how DAD enables people to make intelligent process decisions. Enables effective scaling. DAD provides a foundation from which to scale agile approaches. An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face. For example, consider your approach to exploring the initial scope of your effort. A large team or a geographically distributed team will make different tailoring decisions than a small co-located team. A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments. These are just three of several scaling factors.Makes your process options very clear. The more detailed goals diagrams make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team.Takes the guesswork out of extending agile methods. Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs. Yes, we suppose this claim is true but how do you do so? Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the framework cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues? In short, shouldn’t it be a hybrid? Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here?Makes it clear what risks you’re taking on. By making your process decision options clear, and by describing the trade-offs associated with those options, DAD makes it very clear what risks you’re taking on. Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DAD is going to make it very clear what risks you’ve just taken on by doing so. DAD also makes it clear when this decision is appropriate, so if you’re not in this situation then it is likely time to rethink your approach. Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach. Since the DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects. In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakholder value and here’s why” will be listened to.It hints at an agile maturity model. Scott wrote an article for the December 2012 Cutter IT Journal issue about how DAD and CMMI potentially fit together (DAC members may download this from http://DisciplinedAgileConsortium.org). In that article he suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication. Having said that we have no desire to wade into the agile maturity model morass, but we think it’s an important observation nonetheless.So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations. First, it makes the complexities of solution delivery explicit. Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice. Second, some people just want to be told what to do and actually prefer a prescriptive approach. DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people. Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods.
• #27: This goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods. For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD also indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.First and foremost, DAD is a process decision framework. One what that it achieves this through it’s goal-driven approach that guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face. There are several fundamental advantages to taking a goal driven approach to agile solution delivery. A goal-driven approach:Supports process tailoring. Goal diagram, visit http://DisciplinedAgileDelivery.com for examples, make it very clear how DAD enables people to make intelligent process decisions. Enables effective scaling. DAD provides a foundation from which to scale agile approaches. An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face. For example, consider your approach to exploring the initial scope of your effort. A large team or a geographically distributed team will make different tailoring decisions than a small co-located team. A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments. These are just three of several scaling factors.Makes your process options very clear. The more detailed goals diagrams make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team.Takes the guesswork out of extending agile methods. Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs. Yes, we suppose this claim is true but how do you do so? Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the framework cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues? In short, shouldn’t it be a hybrid? Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here?Makes it clear what risks you’re taking on. By making your process decision options clear, and by describing the trade-offs associated with those options, DAD makes it very clear what risks you’re taking on. Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DAD is going to make it very clear what risks you’ve just taken on by doing so. DAD also makes it clear when this decision is appropriate, so if you’re not in this situation then it is likely time to rethink your approach. Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach. Since the DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects. In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakholder value and here’s why” will be listened to.It hints at an agile maturity model. Scott wrote an article for the December 2012 Cutter IT Journal issue about how DAD and CMMI potentially fit together (DAC members may download this from http://DisciplinedAgileConsortium.org). In that article he suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication. Having said that we have no desire to wade into the agile maturity model morass, but we think it’s an important observation nonetheless.So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations. First, it makes the complexities of solution delivery explicit. Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice. Second, some people just want to be told what to do and actually prefer a prescriptive approach. DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people. Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods.
• #28: This goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods. For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD also indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.First and foremost, DAD is a process decision framework. One what that it achieves this through it’s goal-driven approach that guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face. There are several fundamental advantages to taking a goal driven approach to agile solution delivery. A goal-driven approach:Supports process tailoring. Goal diagram, visit http://DisciplinedAgileDelivery.com for examples, make it very clear how DAD enables people to make intelligent process decisions. Enables effective scaling. DAD provides a foundation from which to scale agile approaches. An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face. For example, consider your approach to exploring the initial scope of your effort. A large team or a geographically distributed team will make different tailoring decisions than a small co-located team. A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments. These are just three of several scaling factors.Makes your process options very clear. The more detailed goals diagrams make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team.Takes the guesswork out of extending agile methods. Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs. Yes, we suppose this claim is true but how do you do so? Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the framework cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues? In short, shouldn’t it be a hybrid? Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here?Makes it clear what risks you’re taking on. By making your process decision options clear, and by describing the trade-offs associated with those options, DAD makes it very clear what risks you’re taking on. Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DAD is going to make it very clear what risks you’ve just taken on by doing so. DAD also makes it clear when this decision is appropriate, so if you’re not in this situation then it is likely time to rethink your approach. Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach. Since the DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects. In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakholder value and here’s why” will be listened to.It hints at an agile maturity model. Scott wrote an article for the December 2012 Cutter IT Journal issue about how DAD and CMMI potentially fit together (DAC members may download this from http://DisciplinedAgileConsortium.org). In that article he suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication. Having said that we have no desire to wade into the agile maturity model morass, but we think it’s an important observation nonetheless.So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations. First, it makes the complexities of solution delivery explicit. Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice. Second, some people just want to be told what to do and actually prefer a prescriptive approach. DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people. Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods.
• #29: This goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods. For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD also indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations.First and foremost, DAD is a process decision framework. One what that it achieves this through it’s goal-driven approach that guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face. There are several fundamental advantages to taking a goal driven approach to agile solution delivery. A goal-driven approach:Supports process tailoring. Goal diagram, visit http://DisciplinedAgileDelivery.com for examples, make it very clear how DAD enables people to make intelligent process decisions. Enables effective scaling. DAD provides a foundation from which to scale agile approaches. An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face. For example, consider your approach to exploring the initial scope of your effort. A large team or a geographically distributed team will make different tailoring decisions than a small co-located team. A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments. These are just three of several scaling factors.Makes your process options very clear. The more detailed goals diagrams make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team.Takes the guesswork out of extending agile methods. Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs. Yes, we suppose this claim is true but how do you do so? Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the framework cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues? In short, shouldn’t it be a hybrid? Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here?Makes it clear what risks you’re taking on. By making your process decision options clear, and by describing the trade-offs associated with those options, DAD makes it very clear what risks you’re taking on. Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DAD is going to make it very clear what risks you’ve just taken on by doing so. DAD also makes it clear when this decision is appropriate, so if you’re not in this situation then it is likely time to rethink your approach. Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach. Since the DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects. In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakholder value and here’s why” will be listened to.It hints at an agile maturity model. Scott wrote an article for the December 2012 Cutter IT Journal issue about how DAD and CMMI potentially fit together (DAC members may download this from http://DisciplinedAgileConsortium.org). In that article he suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication. Having said that we have no desire to wade into the agile maturity model morass, but we think it’s an important observation nonetheless.So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations. First, it makes the complexities of solution delivery explicit. Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice. Second, some people just want to be told what to do and actually prefer a prescriptive approach. DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people. Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods.
• #30: Adoptingand tailoring agile strategies all depend on your circumstances and the range of complexities you faceYou can get guidance from coaches, books, training sessions, etc. But the best approach is to learn and refine your processes as you go. The related question is “how do we know if we’re still getting better, or if we’re just letting things slide because they’re hard?” You should stay focused on your goals and measure your progress.
• #32: For example, DAD says that during Inception, you have the goal of Exploring the Initial Scope of the project. There are several factors involved in exploring the initial scope:There is the level of detail you need to have. Can the level of detail be goals driven, light specifications, or do you need detailed specifications or “Big Requirements Up Front?”There are the types of views you need into those requirements, for example: usage modeling like user stories, usage scenarios, and use cases; there’s Domain modeling to identify major business entities and the relationships between them;the Modeling Strategy – for example, an informal modeling session where the team throws all kinds of stuff up on a whiteboard or doing cool things like paper prototypingWork Item Management Strategy such as a product backlog from Scrum, which the Product Owner prioritizes by value, or a “work item list” which has the Product Owner factoring in risk as well as valueNon-Functional Requirements – are you going to bake these into the User Stories as Acceptance Criteria? Are you going to keep a separate artifact like an NFR list? Would you have technical stories in your work item list?
• #33: For example, DAD says that during Inception, you have the goal of Exploring the Initial Scope of the project. There are several factors involved in exploring the initial scope:There is the level of detail you need to have. Can the level of detail be goals driven, light specifications, or do you need detailed specifications or “Big Requirements Up Front?”There are the types of views you need into those requirements, for example: usage modeling like user stories, usage scenarios, and use cases; there’s Domain modeling to identify major business entities and the relationships between them;the Modeling Strategy – for example, an informal modeling session where the team throws all kinds of stuff up on a whiteboard or doing cool things like paper prototypingWork Item Management Strategy such as a product backlog from Scrum, which the Product Owner prioritizes by value, or a “work item list” which has the Product Owner factoring in risk as well as valueNon-Functional Requirements – are you going to bake these into the User Stories as Acceptance Criteria? Are you going to keep a separate artifact like an NFR list? Would you have technical stories in your work item list?
• #34: People are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team. This is an example of the lean principle of optimizing the whole, in this case the organization, over local optimization at within just the team.By working in an enterprise aware manner DAD teams enjoy:Higher levels of productivity because they are less likely to reinvent the wheelQuicker times to deployment/market because they have less work to doHigher return on investment (ROI) because they have less work to doHigher levels of quality through following common conventions and reuse-----------------------------------------------Scott whitepaper: “DAD teams work within your organization’s enterprise ecosystem, as do all other teams. Typically there are existing systems already in production and minimally your solution shouldn’t impact them. Better yet your solution will hopefully leverage existing functionality, services, 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. Hopefully an agile governance strategy exists which should enhance what your team is doing, improve project visibility and reduce risk.”
• #35: Individual awareness “how can I be the best me?”Team awareness “how can I help the team?”Enterprise awareness “How can I help my organization?”Community awareness “how can I give back to my community?”People are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team. This is an example of the lean principle of optimizing the whole, in this case the organization, over local optimization at within just the team.By working in an enterprise aware manner DAD teams enjoy:Higher levels of productivity because they are less likely to reinvent the wheelQuicker times to deployment/market because they have less work to doHigher return on investment (ROI) because they have less work to doHigher levels of quality through following common conventions and reuse
• #36: Complements self-organizationExample of lightweight governance is the road safety laws: stop at stop signs, signal before changing lanes, don’t follow too closely, etc. These rules of the road are meant to make it so everyone can use the roadways safely together. In the same way, your governance should be light enough that it is sensitive to the fact that self-organizing/self-managing teams are always going to be working to optimize their processes, while at the same time, governance should provide some parameters that everyone needs to follow to ensure your system is strong and sound.Yourgovernance strategy should enhance what your team is doing, improve project visibility, and reduce risk.
• #37: Complements self-organizationExample of lightweight governance is the road safety laws: stop at stop signs, signal before changing lanes, don’t follow too closely, etc. These rules of the road are meant to make it so everyone can use the roadways safely together. In the same way, your governance should be light enough that it is sensitive to the fact that self-organizing/self-managing teams are always going to be working to optimize their processes, while at the same time, governance should provide some parameters that everyone needs to follow to ensure your system is strong and sound.Yourgovernance strategy should enhance what your team is doing, improve project visibility, and reduce risk.Governance is a set of policies that is overseen by a management bodyGovernance establishes chains of responsibil­ity, authority and communication in support of the overall enterprise’s goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. You do this by balancing risk versus return on investment (ROI), setting in place effective processes and practices, defining the direction and goals for the department, and defining the roles that people play with and within the department.The DAD framework includes several important agile governance strategies:Adopting a risk-value driven lifecycleExplicit, light-weight milestone reviewsAgile enterprise teams that work closely with agile teamsRegular coordination meetings (daily standups in Scrum)Iteration/sprint demosAll-hands demosFollow enterprise guidelines (coding standards, UI standards, data conventions, …)Retrospectives, and better yet measured improvementIncreased stakeholder visibilityDevelopment intelligences (BI for IT)Aligning agile team governance with other governance (operations, security, data, …) strategiesAgile measurement/metrics programsActive risk mitigationNamed phasesRobust role definitions
• #40: All of this goes into the work of the teamThis is all captured in the work item list
• #41: All of this goes into the work of the teamThis is all captured in the work item list
• #42: Why do you stand up at your Daily Scrum?Why do you even have daily stand-ups?What is the goal behind this specific process? To coordinate your work. Not “because Scrum says so…”
• #43: Adoptingand tailoring agile strategies all depend on your circumstances and the range of complexities you faceYou can get guidance from coaches, books, training sessions, etc. But the best approach is to learn and refine your processes as you go. The related question is “how do we know if we’re still getting better, or if we’re just letting things slide because they’re hard?” You should stay focused on your goals and measure your progress.
• #44: People are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team. This is an example of the lean principle of optimizing the whole, in this case the organization, over local optimization at within just the team.By working in an enterprise aware manner DAD teams enjoy:Higher levels of productivity because they are less likely to reinvent the wheelQuicker times to deployment/market because they have less work to doHigher return on investment (ROI) because they have less work to doHigher levels of quality through following common conventions and reuse-----------------------------------------------Scott whitepaper: “DAD teams work within your organization’s enterprise ecosystem, as do all other teams. Typically there are existing systems already in production and minimally your solution shouldn’t impact them. Better yet your solution will hopefully leverage existing functionality, services, 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. Hopefully an agile governance strategy exists which should enhance what your team is doing, improve project visibility and reduce risk.”
• #45: Complements self-organizationExample of lightweight governance is the road safety laws: stop at stop signs, signal before changing lanes, don’t follow too closely, etc. These rules of the road are meant to make it so everyone can use the roadways safely together. In the same way, your governance should be light enough that it is sensitive to the fact that self-organizing/self-managing teams are always going to be working to optimize their processes, while at the same time, governance should provide some parameters that everyone needs to follow to ensure your system is strong and sound.Yourgovernance strategy should enhance what your team is doing, improve project visibility, and reduce risk.
• #46: Agile is, at the heart, all about learning. Start somewhere. Scrum is the most popular. But there are many ways to be agile.
• #51: This lifecycle presents a more detailed view of what we call the Agile/Basic DAD lifecycle which extends Scrum’s construction lifecycle. In addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle:It’s iteration based. Like many agile methods, including both Scrum and XP, the solution is built incrementally in a time-boxed manner. These timeboxes are called iterations (what Scrum calls sprints).It uses non-Scrum terminology. Although the lifecycle is Scrum-based we chose to use non-branded terminology in DAD, in the case of this diagram the term iteration instead of sprint. The terminology doesn’t really matter, so if you’re more comfortable with Scrum terminologyuse that instead.It shows inputs from outside the delivery lifecycle. Although the overview diagram above showed only the delivery lifecycle, the detailed diagram below shows that something occurs before the project before Inception and that agile teams often get new requirements (in the form of change requests and defect reports) coming in from production. These inputs provide important context for the overall delivery lifecycle.There is a work item list, not a product backlog. DAD has a greater scope than Scrum, and when you take this greater scope into account you begin to realize you need a more robust change management approach than Scrum’s product backlog. Work items include requirements, defects, and other non-functionality oriented work such as training, vacations, and assisting other teams. All of this work needs to be prioritized somehow, not just implementation of requirements. For more on this, read Agile Best Practice: Prioritized Requirements.In includes explicit milestones. Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that DAD teams should strive to meet. Such milestones are an important aspect of agile governance.We call this the basic/agile lifecycle because it’s likely where you’re going to start with DAD. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach.
• #52: This diagram depicts what we call the Advanced/Lean DAD lifecycle. There are several interesting features to this lifecycle:It supports a continuous flow of delivery. In this lifecycle the solution is deployed as often, and whenever, it makes sense to do so. Work is pulled into the team when there is capacity to do it, not on the regular heartbeat of an iteration.Practices are on their own cadences. With iterations/sprints many practices (detailed planning, retrospectives, demos, detailed modeling, and so on) are effectively put on the same cadence, that of the iteration. With a lean approach the observation is that you should do something when it makes sense to do it, not when the calendar indicates that you’re scheduled to do it.It has a work item pool. All work items are not created equal. Although you may choose to prioritize some work in the “standard” manner, either a value-driven approach as Scrum suggests or a risk-value driven approach as both DAD and RUP suggests, but other work may fit this strategy. Some work, particularly that resulting from legislation, is date driven. Some work must be expedited, such as fixing a severity one production problem. So, a work item pool and not a prioritized stack makes a bit more sense when you recognize these realities.We call this the advanced/lean lifecycle because it’s something we see teams evolve to over time. They often start with the basic lifecycle described earlier but as they learn, as they improve the way that they work, the lifecycle they follow becomes leaner.
• #53: This diagram depicts a Continuous Delivery version of the DAD lifecycle. It is basically a leaner version of the previous lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.