- Context Counts-The Agile Scaling Model
- What Is the Disciplined Agile Delivery (DAD) Process Framework?
- People First
- Learning Oriented
- A Hybrid Process Framework
- IT Solutions over Software
- Goal-Driven Delivery Lifecycle
- Enterprise Aware
- Risk and Value Driven
- Concluding Thoughts
- Additional Resources
DAD teams work within your organization’s enterprise ecosystem, as do other teams, and explicitly try to take advantage of the opportunities presented to them—to coin an environmental cliché “disciplined agilists act locally and think globally.” This includes working closely with the following: enterprise technical architects and reuse engineers to leverage and enhance 2 the existing and “to be” technical infrastructure; enterprise business architects and portfolio managers to fit into the overall business ecosystem; senior managers who should be governing the various teams appropriately; operations staff to support your organization’s overall development and operations (DevOps) efforts; data administrators to access and improve existing data sources; IT development support people to understand and follow enterprise IT guidance (such as coding, user interface, security, and data conventions to name a few); and business experts who share their market insights, sales forecasts, service forecasts, and other important concerns. In other words, DAD teams should adopt what Mark refers to as a “whole enterprise” mindset.
With the exception of startup companies, agile delivery teams do not work in a vacuum. Often existing systems are currently in production, and minimally your solution shouldn’t impact them. Granted, hopefully your solution will leverage existing functionality and data available in production so there will always be at least a minor performance impact without intervention of some kind. You will often have other teams working in parallel to your team, and you may want to take advantage of a portion of what they’re doing and vice versa. Your organizations may be working toward a vision to which your team should contribute. A governance strategy might be in place, although it may not be obvious to you, which hopefully enhances what your team is doing.
Enterprise awareness is an important aspect of self-discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you. Teams developing in isolation may choose to build something from scratch, or use different development tools, or create different data sources, when perfectly good ones that have been successfully installed, tested, configured, and fine-tuned already exist within the organization. We can and should do better by doing the following:
- Leveraging enterprise assets. There may be many enterprise assets, or at least there should be, that you can use and evolve. These include common development guidelines, such as coding standards, data conventions, security guidelines, and user interface standards. DAD teams strive to work to a common infrastructure; for example, they use the enterprise-approved technologies and data sources whenever possible, and better yet they work to the “to be” vision for your infrastructure. But enterprise assets are far more than standards. If your organization uses a disciplined architecture-centric approach to building enterprise software, there will be a growing library of service-based components to reuse and improve upon for the benefit of all current and future solutions. To do this DAD teams collaborate with enterprise professionals—including enterprise architects, enterprise business modelers, data administrators, operations staff, and reuse engineers—throughout the lifecycle and particularly during Inception during envisioning efforts. Leveraging enterprise assets increases consistency and thereby ease of maintenance, decreases development costs and time, and decreases operational costs.
- Enhancing your organizational ecosystem. The solution being delivered by a DAD team should minimally fit into the existing organizational ecosystem—the business processes and systems supporting them—it should better yet enhance that ecosystem. To do this, the first step is to leverage existing enterprise assets wherever possible as described earlier. DAD teams work with operations and support staff closely throughout the lifecycle, particularly the closer you get to releasing into production, to ensure that they understand the current state and direction of the organizational ecosystem. DAD teams often are supported by an additional independent test team—see Chapter 15, “A Typical Day of Construction”—that performs production integration testing (among other things) to ensure that your solution works within the target production environment it will face at deployment time.
- Sharing learnings. DAD teams are learning oriented, and one way to learn is to hear about the experiences of others. The implication is that DAD teams must also be prepared to share their own learnings with other teams. Within IBM we support agile discussion forums, informal presentations, training sessions delivered by senior team members, and internal conferences to name a few strategies.
- Open and honest monitoring. Although agile approaches are based on trust, smart governance strategies are based on a “trust but verify and then guide” mindset. An important aspect of appropriate governance is the monitoring of project teams through various means. One strategy is for anyone interested in the current status of a DAD project team to attend their daily coordination meeting and listen in, a strategy promoted by the Scrum community. Although it’s a great strategy we highly recommend, it unfortunately doesn’t scale very well because the senior managers responsible for governance are often busy people with many efforts to govern, not just your team. In fact Scott found exactly this in the 2010 How Agile Are You? survey. Another approach, one that we’ve seen to be incredibly effective, is for DAD teams to use instrumented and integrated tooling, such as Rational Team Concert (RTC), which generates metrics in real time that can be displayed on project dashboards. You can see an example of such a dashboard for the Jazz™ team itself at www.jazz.net, a team following an open commercial strategy. Such dashboards are incredibly useful for team members to know what is going on, let alone senior managers. A third strategy is to follow a risk-driven lifecycle, discussed in the next section, with explicit milestones that provide consistent and coherent feedback as to the project status to interested parties.