Agility@Scale: Strategies for Scaling Agile Software Development

I recently wrote a detailed article about Large Agile Teams that was a detailed walkthrough of how to structure agile teams of various sizes.  I suspect that this is the most comprehensive online discussion of this topic.  The article addressed the following topics:

1. Organizing Agile Teams.  The article starts with a summary of the results of some industry research that I've done regarding the size of agile teams, showing that agile techniques are in fact being successfully applied on a variety of team sizes.  It then goes into detail describing the organization structure of agile teams at various sizes.  The article starts with a discussion of small agile teams, covering the common rhetoric of how to organize such a team and then making observations about what actually happens in practice.  It then walks through two approaches to organizing medium sized teams of 15 to 50 people - a structure for a single team and a structure for a team of teams.  Finally, it walks through how to organize a large agile program of 50+ people, focusing a fair bit on the need for a leadership team to coordinate the overall activities within the program.  This advice is similar to what is seen in the SAFe framework although proves to be a bit more flexible and pragmatic in practice.
2. Supporting Large Agile Teams.  The leadership structure to support a large agile team is reasonably straightforward once you understand the issues that such a team faces.  In this section the article overviews the need for three important sub teams within your overall leadership team: The Product Delivery Team, The Product Management Team, and The Architecture Team.  It also describes the need for an optional Independent Testing/Integration Team, something misleadingly labeled an integration team in SAFe, that reflects some of the known agile testing and quality practices that I've been writing about for several years.
3. Organizing subteams.  The article includes a detailed discussion for how to organize the work addressed by agile sub teams within a large agile program.  These strategies include feature teams, component teams, and internal open source teams.  As you would expect with the Disciplined Agile Delivery (DAD) framework, the article clearly summarizes the advantages and disadvantages of each approach on provides guidance for when (not) to apply each one.  I suspect you'll find this portion of the article to be one of the most coherent discussions of the Feature vs. Component team debate.
4. Tailoring agile practices.  The article provides a detailed overview of how the various DAD process goals are tailored to address the issues faced by large teams.  This advice includes:  Do a bit more up-front requirements exploration; Do a bit more up-front architectural modelling; Do a bit more initial planning; Adopt more sophisticated coordination activities; Adopt more sophisticated testing strategies; and Integrate regularly.  My hope is that you find this part of the article very illuminating regarding how the DAD framework provides flexible and lightweight advice for tailoring your approach to address the context of the situation that you face.
5. Other Resources.  The article ends with a collection of links to other resources on this topic.

I welcome any feedback that you may have about Large Agile Teams.

The following diagram summarizes a safe and proven strategy for scaling agile delivery strategies at the team level.  There are three features of this strategy:

1. Basic agile and lean methods.   At the base are methods such as Scrum, Extreme Programming (XP), Agile Modeling, Kanban, Agile Data, and many others.  These methods are the source of practices, principles, and strategies that are the bricks from which a team will build its process. 
2. Disciplined Agile Delivery (DAD).  Building on mainstream methods is the DAD process decision framework, providing an end-to-end approach for agile software delivery.  DAD provides the process mortar required to combine the process bricks, effectively doing the “heavy lifting” to describe how all of these great agile strategies fit together.
3. Agility at scale.  Teams operating at scale apply DAD in a context driven manner to address the scaling factors that they face.  These teams may be large, they may be geographically distributed in some way, they may face compliance constraints, they may be addressing a complex domain or technical environment, or they may be organizationally distributed in some manner.  And usually combinations thereof.  Without the solid foundation provided by DAD, agility at scale is incredibly difficult to achieve.

To scale agile successfully you must be able to tailor your approach to reflect the context that you face.  To do this you must understand what your process and organizational structure options are and what tradeoffs each of those options has.  Unless you’re a process expert, this can be challenging.  This is where DAD’s process goal strategy comes in.  Instead of prescribing a single way to do things, as we see in methods such as Scrum and SAFe, DAD instead captures your options in terms of process goals and guides you through making the decisions that best address the situation that you find yourself in.  An example of a process goal diagram, in this case for the Inception phase goal Explore Initial Scope, is shown below. 

The critical thing is that with a goal-driven approach it becomes much easier to understand how to scale agile.  Depending on the context of the situation that a team finds itself in you will address each goal differently.  The strategy for a small, co-located team facing a fairly straightforward situation in a non-regulatory environment works well for that team, the same strategy prescribed to a team in a different situation would put that team at risk of failure.  Instead of prescribing a single way of working that is optimized for a specific situation we need to instead allow, and better yet enable, teams to adopt strategies that reflect the context of the situation that they face.  

We’ve found that four of the twenty-two process goals seem to take about 80% of the tailoring impact.  These goals are:

1. Explore Initial Scope. This is sometimes referred to as initially populating the backlog in the Scrum community, but there is far more to it than just doing that.  This is an important goal for several reasons.  First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding.  Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost.  Having an understanding of the scope of your effort is important input into answering those sorts of questions.
2. Identify Initial Technical Strategy. This is sometimes referred to as initial architecture envisioning or simply initial architecture modeling. You want to address this process goal for several reasons . First, the team should think through, at least at a high level, their architecture so as to identify a viable strategy for moving forward into Construction.  A little bit of up-front thinking can increase your effectiveness as a team by getting you going in a good direction early in the lifecycle.  It can also help to avoid injection of unnecessary technical debt as a result.  Second, the team should strive to identify the existing organizational assets, such as web services, frameworks, or legacy data sources that they can potentially leverage while producing the new solution desired by their stakeholders.  By doing this you increase the chance of reuse, thereby avoiding adding technical debt into your organizational ecosystem, and more importantly you reduce the time and cost of delivering a new solution as the result of reuse.  You will do this by working with your organization’s enterprise architects, if you have any.  This is an aspect of DAD’s philosophy of working in an enterprise aware manner.
3. Move Closer to a Deployable Release.  This Construction phase process goal is important for three reasons. First, it encompasses the packaging aspects of solution development (other important development aspects are addressed by its sister goal Produce a Potentially Consumable Solution).  This includes artifact/asset management options such as version control and configuration management as well as your team’s deployment strategy.  Second, it provides deployment planning options, from not planning at all (yikes!) to planning late in the lifecycle to the more DevOps-friendly strategies of continuous planning and active stakeholder participation. Third, this goal covers critical validation and verification (V&V) strategies, many of which push testing and quality assurance “left in the lifecycle” so that they’re performed earlier and thereby reducing the average cost of fixing any defects.
4. Coordinate Activities. Although it is nice to believe that all of the coordination required by an agile team can be handled with a 15 minute stand up meeting every day the truth is far from that.  This process goal addresses strategies for coordinating the work within a team, coordinating with other development teams (if needed), coordinating with IT groups such as your Enterprise Architects or data management group, and coordinating between subteams a programme or portfolio.

For a more detailed discussion of how these four process goals are the key to scaling your agile software delivery process, please refer to the whitepaper Scaling Agile Software Development: Disciplined Agile Delivery at Scale.  

I was recently involved in an online discussion about how to calculate the benefits realized by software development teams.   As with most online discussions it quickly devolved into camps and the conversation didn’t progress much after that.  In this case there was what I would characterize as a traditional project camp and a much smaller agile/lean product camp.  Although each camp had interesting points, the important thing for me in the conversation was the wide cultural and experience gap between the people involved in the conversation.

The following diagram summarizes the main viewpoints and the differences between them.  The traditional project camp promoted a strategy where the potential return on investment (ROI) for a project would be calculated, a decision would be made to finance the project based (partly) on that ROI, the project would run, the solution delivered into production, and then at some point in the future the actual ROI would be calculated.  Everyone was a bit vague on how the actual ROI would be calculated, but they agreed that it could be done although would be driven by the context of the situation.  Of course several people pointed out that it rarely works that way.  Even if the potential ROI was initially calculated it would likely be based on wishful thinking and it would be incredibly unlikely that the actual ROI would be calculated once the solution was in production.  This is because few organizations are actually interested in investing the time to do so and some would even be afraid to do so.  Hence the planned and actual versions of the traditional strategy in the diagram.

The agile/lean camp had a very different vision.  Instead of investing in upfront ROI calculation, which would have required a fair bit of upfront requirements modelling and architectural modelling to get the information, the idea was that we should instead focus on a single feature or small change.  If this change made sense to the stakeholders then it would be implemented, typically on the order of days or weeks instead of months, and put quickly into production.  If your application is properly instrumented, which is becoming more and more common given the growing adoption of DevOps strategies, you can easily determine whether the addition of the new feature/change adds real value.

Cultural differences get in your way  

The traditional project camp certainly believed in their process.  In theory it sounded good, and I’m sure you could make it work, but in practice it was very fragile.  The long feedback cycle, potentially months if not years, pretty much doomed the traditional approach to measuring benefits of software development to failure. The initial ROI guesstimate was often a work of fiction and rarely would it be compared to actuals.  The cultural belief in bureaucracy motivated the traditional project camp to ignore the obvious challenges with their chosen approach.

The agile/lean camp also believed in their strategy.  In theory it works very well, and more and more organizations are clearly pulling this off in practice, but it does require great discipline and investment in your environment.  In particular, you need investment in modern development practices such as continuous integration (CI), continuous deployment (CD), and instrumented solutions (all important aspects of a disciplined agile DevOps strategy).  These are very good things to do anyway, it just so happens that they have an interesting side effect of making it easy (and inexpensive) to measure the actual benefits of changes to your software-based solutions.  The cultural belief in short feedback cycles, in taking a series of smaller steps instead of one large one, and in their ability to automate some potentially complex processes motivated the agile/lean camp to see the traditional camp as hopeless and part of the problem.  

Several people in the traditional project camp struggled to understand the agile/lean approach, which is certainly understandable given how different that vision is compared with traditional software development environments.  Sadly a few of the traditionalists chose to malign the agile/lean strategy instead of respectfully considering it.  They missed an excellent opportunity to learn and potentially improve their game.  Similarly the agilists started to tune out, dropping out of the conversation and forgoing the opportunity to help others see their point of view.  In short, each camp suffered from cultural challenges that prevented them from coherently discussing how to measure the benefits of software development efforts.

How Should You Measure the Effectiveness of Software Development?

Your measurement strategy should meet the following criteria:

1. Measurements should be actioned.  Both the traditional and agile/lean strategies described above meet this criteria in theory.  However, because few organizations appear willing to calculate ROI after deployment as the traditional approach recommends, in practice the traditional strategy rarely meets this criteria.  It is important to note that I used the word actioned, not actionable.  Key difference.
2. There must be positive value.  The total cost of taking a measure must be less than the total value of the improvement in decision making you gain.  I think that the traditional strategy falls down dramatically here, which is likely why most organizations don’t actually follow it in practice.  The agile/lean strategy can also fall down WRT this criterion but is much less likely to because the feedback cycle between creating the feature and measuring it is so short (and thus it is easier to identify the change in results to the actual change itself).
3. The measures must reflect the situation you face.  There are many things you can measure that can give you insight into the ROI of your software development efforts.  Changes in sales levels, how often given screen or function is invoked, savings incurred from a new way of working, improved timeliness of information (and thereby potentially better decision making), customer retention, customer return rate, and many others.  What questions are important to you right now?  What measures can help provide insight into those questions?  It depends on the situation that you face, there are no hard and fast rules.  For a better understanding of complexity factors faced by teams, see The Software Development Context Framework.
4. The measures should be difficult to game.  Once again, traditional falls down here.  ROI estimates are notoriously flakey because they require people to make guesses about costs, revenues, time frames, and other issues.  The measurements coming out of your instrumented applications are very difficult to game because they’re being generated as the result of doing your day-to-day business.  
5. The strategy must be compatible with your organization.  Once again, this is a “it depends” type of situation.  Can you imagine trying to convince an agile team to adopt the traditional strategy, or vice versa?  Yes, you can choose to improve over time.  

Not surprisingly, I put a lot more faith in the agile/lean approach to measuring value.  Having said that, I do respect the traditional strategy as there are some situations where it may in fact work. Just not as many as traditional protagonists may believe.

On Twitter one of the people that I follow recently tweeted in jest "I am waste".  He had been tweeting about the problem that people will often pay consultants for their advice yet will not follow that advice once it's been provided (yet will often still keep paying for more advice).  Perhaps in this situation his efforts were a waste, or perhaps the real issue was that the customer had a long learning process and hadn't yet come to the point where they were willing to act on the advice, we may never know.  But I have to think that there are other situations where this person isn't a waste, regardless of his claims.

This got me thinking that something is a waste in one context yet in another context may be quite valuable.  Or, as the old saying goes, one man's trash is another man's treasure.

For example, consider the following simple value stream: 

[Activity A: 10 min] [Wait time: 20 min] [Activity B: 10 min]

Without considering the context, the wait time of 20 min represents 50% waste in the overall process that we should try to eliminate.

What if that wait time provides people with a much needed rest?  With time to contemplate?  With time to destress?  Eliminating that wait time, or even reducing it, could result a degradation of performance.  In this case, one person's waste (the wait time) is another person's treasure (rest time).  The implication is that we need to work closely with the people intimately involved in a process if we're to help them to improve it.

Context counts.

Recently I have been asked by several customer organizations to help them to understand how to account for the expense of agile software development. In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations. The details of accounting rules vary between countries, but the fundamentals are common.  In order to get properly account for the costs incurred by software development teams you need to keep track of the amount of work performed and the type of work performed to develop a given solution. Time tracking doesn't have to be complex: at one customer developers spend less than five minutes a week capturing such information.

Why is Time Tracking Potentially Valuable?

There are several financial issues to be aware of:

• Capitalization. For public companies capital expenses (CapEx) can potentially boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, operational expenses (OpEx) are accounted for in the year that they occur and thereby reduce net income which in turn reduces your organization's taxes for that year.
• Matching. One of the goals of good accounting is to accurately reflect the net income of the enterprise and to prevent income manipulation or "smoothing". As such a key tenet is the principle of matching revenues with the appropriate expenses. For software this means that we expense the cost of the software over the lifetime of the asset against the income at that time. An implication of this is that capitalizing software development, when appropriate, before the software goes into production clearly violates the matching principle since there is no benefit of the asset until such time.
• Tax Credits.  In some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature.

The point is that the way that a software developer's work is accounted for can have a non-trivial impact upon your organization's financial position.

What Do Agilists Think of Time Tracking?

So, I thought I'd run a simple test. Last week on LinkedIn's Agile and Lean Software Development group I ran a poll to see what people thought about time tracking. The poll provided five options (a limitation of LinkedIn Polls) to choose from:

• Yes, this is a valuable activity (33% of responses)
• Yes, this is a waste of time (39% of responses)
• No, but we're thinking about doing so (2% of responses)
• No, we've never considered this (18% of responses)
• I don't understand what you're asking (5% of responses, one of which was mine so that I could test the poll)

The poll results reveal that we have a long way to go. Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity. When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars. Looking at it from a dollar per minute point of view, it could be the highest value activity that a developer performs in a given week.

The discussion that ensued regarding the poll was truly interesting. Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking. Some comments that stood out for me included:

• It's a colossal waste of time unless you're billing a customer by the hour.
• We record time spent on new development work (as distinct from other tasks such as bug fixing in legacy code and so on) as this is capitalised as an asset and depreciated.
• I think the *most* pointless example was where the managers told us what we should be putting in.
• One day we will move past the "just do it" mentality and have some meaningful conversations and the reasons for what we do.
• In my experience time tracking is a massive waste... of time. It's a poor substitute for management.
• Why do you need to know more than the info available through Sprint Backlog, Sprint burndown and the daily standup?
• Some of my teams (I am SM for three teams) are skeptical about this. They do not think that keeping track of task hours this way will be any more useful than the daily standup reports. And they do not believe that Management can resist the temptation to use task hours as a measure.

I think that there are several interesting implications from this discussion:

1. Agilists need to become more enterprise aware. It's clear to be really effective that agile delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they're doing.  In Disciplined Agile Delivery (DAD) this is something that we refer to as being enterprise aware.  There's far more to enterprise awareness than understanding pertinent accounting principles, for interest disciplined agile teams work towards a common technology roadmap and common business roadmap, but appreciating why time tracking is a potentially valuable activity would be a good start.
2. Management needs to communicate better.  It's also clear that management needs to communicate more effectively regarding why they're asking people to track their time. To be fair, management themselves might not be aware of the tax implications themselves so may not be making effective use of the time data they're asking for.
3. Management needs to govern more effectively. Several people were clearly concerned about how management was going to use the time data (by definition they are measures) which could be a symptom of both poor communication as well as poor governance (unfortunately many developers have experiences where measures have been used against them, a failure of governance, and no longer trust their management teams to do the right thing as a result).
4. Time tracking should be streamlined.  It was obvious from the conversation that several people worked in organizations where the time tracking effort had gotten completely out of hand.  Spending 5 minutes a week is ok, and to be quite blunt should be more than sufficient, but spending fifteen minutes or more a day doing so is far too much.  Over the years I've helped organizations design measurement programs and I've seen a lot of well-intention efforts become incredibly onerous and expensive for the people they were inflicted upon.  I suspect it's time for a reality check in some of these organizations people were alluding to.  A good heuristic is that for any measurement you should be able to indicate the real cost of collecting it, the use(s) that the information is being put to, and the value resulting from those uses.  If you can't quickly and coherently do that then you need to take a hard look at why you continue to collect that metric.  The lament "we might need it one day" is a symptom that you're wasting time and money.
5. Agile rhetoric is getting in the way.  Some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and stand up meetings may be preventing people from becoming enterprise aware because they believe that all of their management needs are being met by them.
6. You may be missing out on the benefits of time tracking.  Many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.

Parting Thoughts

Disciplined agilists are enterprise aware. This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization. In the anecdote I provided it was clear that many agile developers believe that an activity such as time tracking is a waste when that clearly doesn't have to be the case. Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization.

Granted, time tracking on an agile project team is nowhere near as sexy as topics such as continuous integration (CI), TDD, the definition of done, continous architecture, or many more.  But you know what?  Although it's a mind-numbingly mundane issue it is still an important one. 'Nuff said (I hope).

1. Disciplined Agile Yellow Belt. This beginner certification indicates to colleagues and employers that you are eager to learn Disciplined Agile Delivery (DAD) strategies that enable you to increase your skills and abilities as a software professional.
2. Disciplined Agile Green Belt. This intermediate certification indicates that you are experienced at DAD and are on your way to becoming a generalizing specialist. You have the potential to be a “junior coach” under the guidance of a senior coach (someone who is likely a Disciplined Agile Black Belt).
3. Disciplined Agile Black Belt. This expert certification indicates that you are a trusted expert with significant proficiency at DAD. You can coach other people in disciplined agile strategies and advise organizations in the adoption and tailoring of the DAD framework.

Differentiate yourself in the marketplace. Certification in Disciplined Agile Delivery (DAD) means something to clients and employers because it needs to be earned. Certification in DAD tells the marketplace you understand how to deliver an agile solution from end-to-end with experience in enterprise-class development.

1. You adopt "standard" agile discipline.   Aspects of agile which require discipline include adopting practices such as test-driven development (TDD), active stakeholder participation, working collaboratively, shortening the feedback cycle, and many more.  These strategies are a great start to becoming disciplined IT professionals. 
2. You take a goal-driven approach.  When we first started working on the DAD framework I didn't want to create yet another prescriptive framework, particularly given Rational's track record with the Rational Unified Process (RUP) framework.  Rational has been pilloried for years for the prescriptive nature of RUP, which is unfortunate because there are a lot of great ideas in RUP that agile teams can benefit from, some of which we adopted in DAD and many of which are being actively reinvented with the agile community even as you read this. Furthermore, there are many prescriptive elements of the Scrum method that can get teams in trouble.  For example, Scrum prescribes that you hold a daily stand up meeting, often called a Scrum meeting, where everyone should answer three questions.  That's a great approach for teams new to agile, but it proves problematic in many situations due to it's prescriptive nature. Do you really need to do this once a day?  I've been on teams where we held coordination meetings twice a day and others only once a week.  Do you really need to stand up?  I've been on geographically distrubited agile teams where many of us were sitting down during coordination calls.  Do you really need to answer three questions, two of which are clearly focused on status regardless of claims otherwise?  I've been on lean teams where we met around our Kanban board and focused on potential blockers.  The answers to these questions depends on the context of the situation you find yourself in.  The challenge, at least from the point of view of a process framework, is how do you avoid falling into the trap of being overly prescriptive.  The strategy we adopted in DAD is to take a goal-driven approach.  The observation is that regardless of the situation you find yourself in there are common goals your team will need to fulfill.  For example, at the beginning of a project common goals include developing an initial plan, initially exploring the scope, initially identifying a technical strategy, and securing initial funding (amongst others).  Throughout construction you should coordinate your activities, improve the quality of your ecosystem, and produce a potentially consumable solution on a regular basis (more on this below).  So, instead of prescribing a daily stand up meeting the DAD framework instead indicates you should coordinate your activities, and gives several options for doing so (one of which is a Scrum meeting).  More importantly DAD describes the advantages and disadvantages of your options so that you can make the choice that's best suited for the situation your team finds itself in (see this blog posting for a detailed example of the types of tables included in the DAD book to help you through such process tailoring decisions).  In short, our experience is that it requires discipline to take a goal driven approach to agile delivery over the prescriptive strategies in other agile processes. 
3. You take a context-driven approach.  There are many tailoring factors, which I describe in the Software Development Context Framework (SDCF), which you need to consider when making process, tooling, and team structure decisions.  For example, a large team will adopt a different collection of practices and tools than a small team.  A geographically distributed team will adopt a different strategy than a team that is co-located.  You get the idea.  Other tailoring factors include compliance, team culture, organization culture, technical complexity, domain complexity, and project type.  It requires discipline to recognize the context of the situation you find yourself in and then act accordingly.
4. You deliver potentially consumable solutions.  One of the observations that we made early in the development of the DAD framework was that disciplined agile teams produce potentially consumable solutions, not just potentially shippable software.  Although delivery of high-quality, working software is important it is even more important that we deliver high-quality working solutions to our stakeholders. For example, not only are we writing software but we may also be updating the hardware on which it runs, writing supporting documentation, evolving the business processes around the usage of the system, and even evolving the organizational structure of the people working with the system.  In other words, disciplined agilists focus on solutions over software.  Furthermore, "potentially shippable" isn't sufficient: not only should it be shippable but it should also be usable and should be something people want to use.  In other words it should be consumable (a concept DAD adopted from IBM's Outside In Development).  Minimally IT professionals should have the skills and desire to produce good software, but what they really need are the skills and desire to provide good solutions. We need strong technical skills, but we also need strong "soft skills" such as user interface design and process design to name just two. The incremental delivery of potentially consumable solutions on an incremental basis requires discipline to do successfully.  DAD teams focus on repeatable results not repeatable processes.
5. You are enterprise aware.   Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you will need to act accordingly. It takes discipline to work with enterprise professionals such as enterprise architects, data admistrators, portfolio managers, or IT governance people 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.  It requires discipline to accept and potentially enhance existing corporate development conventions (programming guidelines, data guidelines, UI guidelines, ...).  It requires discipline to accept that your organization has an existing technology roadmap that you should be leveraging, building out, and in some cases improving as you go.  In short, enterprise awareness requires a level of discipline not typically seen on many agile teams.
6. You adopt a full delivery lifecycle.  Empirically it is very easy to observe that at the beginning of an agile project there are some activities that you need to perform to initiate the project.  Similarly at the end of the project there are activities that you need to perform to release the solution into production or the marketplace.  The DAD process framework addresses the effort required for the full delivery effort, including project initiation, construction, and deployment.  Our experience is that it requires discipline on the part of IT professionals to include explicit phases for Inception/Initation, Construction, and Transition/Deployment and more importantly to focus the appropriate amount of effort on each.  One danger of explicit phases is that you run the risk of taking what's known as a Water-Scrum-Fall approach, a term coined by Dave West the person who wrote the forward for the DAD book, where you take an overly heavy/traditional approach to inception and transition in combination with a lighter agile approach to construction.  Water-Scrum-Fall occurs because many organizations haven't made a full transition to agile, often because they think it's only applicable to construction.  Our experience is that you can be very agile in your approach to inception and transition, experience we've built into the DAD framework.  Having said that it clearly requires discipline to keep inception activities short and similarly it requires discipline to reduce the "transition phase" to an activity. 
7. You adopt a wider range of roles.  An interesting side effect of adopting a full delivery lifecycle is that you also need to adopt a more robust set of roles.  For example, the Scrum method suggests three roles - Scrum Master, Product Owner, and Team Member - a reflection of the Scrum lifecycle's construction focus.  DAD suggests three primary roles - Team Lead, Product Owner, Team Member, Architecture Owner, and Stakeholder - as well as five secondary roles which may appear at scale.   
8. You embrace agile governance.  Governance 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.  It requires discipline to adopt an agile approach to governance, and that's something built right into the DAD framework.

1. Initial requirements envisioning.  Disciplined agile teams invest time at the beginning of the project to identify the high-level scope in a light-weight, collaborative manner.  This includes common operations requirements such as the need to backup and restore data sources, to instrument the solution so that it can be monitored in real time by operations staff, or to architect the solution in a modular manner to enable easier deployment. 
2. Initial architecture envisioning. Disciplined agile teams will also identify a viable architectural strategy which reflects the requirements of their stakeholders and your organization’s overall architectural strategy (hence the need to work closely with your enterprise architects and operations staff).  One goal is to ensure that the team is building (or buying) a solution which will work well with the existing operational infrastructure and to begin negotiating any infrastructural changes (such as deploying new technologies) early in the project.   Another goal is to ensure that operations-oriented requirements are addressed by the architecture from the very start. 
3. Initial release planning.  As part of release planning the disciplined agile team works closely with their operations group to identify potential release windows to aim for, any release blackout periods to avoid, and the need for operations-oriented milestone reviews later in the lifecycle (if appropriate).
4. Active stakeholder participation.  Disciplined agile teams work closely with their stakeholders, including both operations and support staff, all the way through the lifecycle to ensure that their evolving needs are understood.   
5. Continuous integration (CI).  This is a common technical agile practice where the solution is built/compiled, regression tested, and maybe even run through code analysis tools.  CI promotes greater quality which in turn enables easier releases into production.  
6. Parallel independent testing. For enterprise-class development or at scale, particularly when the domain or technology is very complex or in regulatory environments, disciplined agile team will find they need to support their whole team testing efforts with an independent test team running in parallel to the development team.  These testing issues often include validation of non-functional requirements – such as security, performance, and availability concerns – and around production system integration.  All of these issues are of clear importance for operations departments.   
7. Continuous deployment.  With this practice you automate the promotion of your working solution between environments.  By automating as much of the deployment effort as possible, and by running it often, the development team increases the chance of a successful deployment and thereby reduces the risk to the operations environment. Note that deployment into production is generally not automatic, as this is an important decision to be made by your operations/release manager(s). 
8. Continuous documentation.  With this practice supporting documentation, including operations and support documentation, is evolved throughout the lifecycle in concert with the development of new functionality. 
9. Production release planning.  This is the subset of your release planning efforts which focuses on the activities required to deploy into production. 
10. Production readiness reviews.  There should be at least one review, performed by the person(s) responsible for your operations environment, before the solution is deployed into production.  The more critical the system, the more product readiness reviews may be required. 
11. End-of-lifecycle testing.  Minimally you will need to run your full automated regression test suite against your baselined code once construction ends.  There may also be manual acceptance reviews or testing to be performed, and any appropriate fixing and retesting required to ensure that the solution is truly ready for production. 

•  People are assigned to a single team
•  Development teams have easy access to business expertise
• Development teams are organized for agile delivery (not traditional)
• Your organization has an agile support group/community of excellence
• Your organization is explicitly addressing barriers to agility
• There is executive sponsorship for agile
• Agile teams are measured on value creation
• Your organization's IT governance strategy includes an agile path
  

• What are the challenges typically faced by Disciplined Agile Development teams as they begin to transition their working solutions into production?
• How best could this gap between Development and Operations be closed so that they worked collaboratively rather than in silos?
  
• If this DevOps gap was decreased or even closed, what would the measurable value be to Agile projects and their business stakeholders?