The Disciplined Agile (DA) tool kit is organized into four layers, overviewed in Figure 1. These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE). This blog focuses on the Disciplined DevOps layer.
How is "Disciplined DevOps" different from normal/mainstream DevOps? Mainstream DevOps is the streamlining of software development, information technology (IT) operations, and support. This strategy is often depicted as an infinite loop as you see in Figure 2. Disciplined DevOps is an enterprise-ready approach that extends mainstream DevOps to include critical activities around security, data management, release management, and business operations. The high-level workflow for Disciplined DevOps is depicted in Figure 3.
Let's explore the components of Disciplined DevOps. The hexes in Figure 3 represent process blades, sometimes called process areas. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner. Process blades also address functional roles specific to that domain as well as extensions to the DA mindset specific to that domain. The process blades of Disciplined DevOps are:
Disciplined Agile Delivery (DAD) is a people-first, learning-oriented hybrid approach to solution delivery. DAD teams focus on the creation of a new, or evolution of an existing, consumable solution for their customers. A solution may include any combination of software, physical assets (e.g. hardware), documentation, changes to the supported business process, and changes to the organizational structure(s) of the people involved. A solution is consumable when it is usable, desirable, and functional. DAD enables a flexible way of working (WoW), supporting several lifecycles in a manner that is tactically scalable.
The Security process blade focuses on how to protect your organization from both information/virtual and physical threats. This includes procedures for security governance, identity and access management, security policy management, incident response, and vulnerability management. As you would expect these policies will affect your organization’s strategies around change management, disaster recovery and business continuity, solution delivery, and vendor management. For security to be effective it has to be a fundamental aspect of your organizational culture.
Data management is the development, execution and supervision of plans, policies, programs and practices that control, protect, deliver and enhance the value of data and information assets. DA promotes a pragmatic, streamlined approach to data management that fits into the rest of your organizational processes – we need to optimize the entire workflow, not sub-optimize our data management strategy. Disciplined agile data management does this in an evolutionary and collaborative manner, via concrete data management strategies that provide the right data at the right time to the right people.
The release management process blade encompasses planning, coordinating, and verifying the deployment of solutions into production. Release management requires collaboration by the team(s) producing the solutions and the people responsible for your organization’s operational environment(s). In the case of organizations with a “you build it, you run it” DevOps mindset these people may be one in the same, although even in these situations you will often find a group of people responsible for governing the overall release management effort. In a true DevOps environment release management is fully automated for the intangible aspects (e.g. software and supporting documentation), and perhaps even some physical aspects, of your solution.
Support focuses on helping customers/end users to work with the solutions produced by your delivery teams. Ideally your solutions should be designed so well that people don’t need anyone to help them but unfortunately it doesn’t always work out that way. So in many ways your support strategy is your “last line of defense” in your efforts to Delight Customers. Support goes by many names, including help desk, customer support, and customer care.
The primary aim of IT operations is to run a trustworthy IT ecosystem. From the point of view of your customers, you want to do such a good job that they don’t even notice IT. For older organizations this can be a challenge due to the existence of hundreds, if not thousands, of legacy systems that have been deployed over the decades. You may face daunting technical debt in these systems – poor quality data, overly complex or poorly written source code, systems with inadequate automated regression tests (if any), different versions of the same system, several systems offering similar functionality, numerous technology platforms, systems and technologies for which you have insufficient expertise, and more.
Business operations is one of the process blades of the value stream layer, although as you see in Figure 3 it is a critical component of the Disciplined DevOps workflow. Business operations focuses on the activities required to provide services to customers and to support your products. The implementation of business operations will vary by value stream, in a bank retail account services is implemented in a very different manner than brokerage services for example. Business operations includes help desk and support services (integrated in with IT support where appropriate) as well as any technical sales support activities such as training, product installation, and product customization. As you can imagine close collaboration with both your Sales and Marketing efforts is required to successfully Delight Customers.
This paper describes, step-by-step, how to evolve from today’s Scrum vision of agile software development to a disciplined agile solution delivery. It begins with a brief overview of the agile software development movement and its implications. We then overview the Scrum method with its associated benefits and drawbacks, and then how to move beyond Scrum to a full delivery process framework called Disciplined Agile Delivery (DAD). DAD is a governed, hybrid approach that provides a solid foundation from which to scale agile solution delivery within enterprise-class organizations. The steps to do this are:
You can download the paper here.
Non-functional requirements, also known as quality of service (QoS) or technical requirements, are typically system-wide thus they apply to many, and sometimes all of your functional requirements. Part of ensuring that your solution is potentially consumable each iteration is ensuring that it fulfill its overall quality goals, including applicable NFRs. This is particularly true with life-critical and mission-critical solutions. Good sources for NFRs include your enterprise architects and operations staff, although any stakeholder is a potential source for NFRs.
As your stakeholders tell you about functional requirements they will also describe non-functional requirements (NFRs). These NFRs may describe security access rights, availability requirements, performance concerns, or a host of other issues as saw in my blog regarding initial architecture envisioning. There are three basic strategies, which can be combined, for capturing NFRs: technical stories; acceptance criteria for individual functional requirement (such as stories); and an explicit list.
So what are the implications for implementing NFRs given the three previous capture strategies? Although in the DAD book we make this sort of comparison via a table to improve consumability, in this blog posting I will use prose due to width constraints. Let’s consider each one:
In most situations you should maintain an explicit list and then use that to drive identification of acceptance criteria as we’ve found that it’s more efficient and lower risk in the long run. Of course capturing NFRs is only one part of the overall process of addressing them. You will also need to implement and validate them during construction, as well as address them in your architecture.
An important issue which goes to NFRs such as consumability, supportability, and operability, is that of deliverable documentation. At the start of the project is the best time to identify the required documentation that must be created as part of the overall solution. This potentially includes operations manuals, support manuals, training materials, system overview materials (such as an architecture handbook), and help manuals to name a few. These deliverable documents will be developed and kept up to date via the continuous documentation practice.
An important aspect of Disciplined Agile Delivery (DAD) is its explicit inclusion of an Inception phase where 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. Some people will mistakenly refer to this effort this Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2009 Agile Project Initiation survey found the average agile team spends 3.9 weeks in Inception and the November 2010 Agile State of the Art survey found that agile teams have Construction iterations of a bit more than 2 weeks in length).
Regardless of terminology, agile teams are doing some up front work. Part of that initial work is identifying an initial technical architecture, typically via some initial architecture envisioning http://www.agilemodeling.com/essays/initialArchitectureModeling.htm. Because your architecture should be based on actual requirements, otherwise you’re “hacking in the large”, your team will also be doing some initial requirements envisioning http://www.agilemodeling.com/essays/initialRequirementsModeling.htm in parallel. Your architecture will be driven in part by functional requirements but more often the non-functional requirements, also called quality of service (QoS) or simply quality requirements. Some potential quality requirements are depicted in the figure below (this figure is taken from the Disciplined Agile Delivery book but was first published in Agile Architecture Strategies ).
Some architects mistakenly believe that you need to do detailed up front modeling to capture these quality requirements and then act upon them. This not only isn’t true it also proves to be quite risky in practice, see my discussion about Big Modeling Up Front (BMUF) for more details. Disciplined agilists instead will do just enough initial modeling up front and then address the details on a just-in-time (JIT) basis throughout construction. Of course it’s important to recognize that just enough will vary depending on the context of the situation, teams finding themselves at scale will need to do a bit more modeling than those who don’t. It’s also important to recognize that to address non-functional requirements throughout construction that you need to have more than just architectural modeling skills. This topic will be the focus of my next blog posting in this series.
Recently at the Scott W. Ambler + Associates site we received a series of questions from someone who wanted to better understand how architecture issues are addressed on agile project teams. It seemed to me that the questions were sufficiently generic to warrant a public response instead of a private one. So, over the next few days I’m going to write several blog postings here to address the issues that were brought up in the questions. It’s important to note that I will be answering from the point of view of Disciplined Agile Delivery (DAD), and not agile in general. Other agile methods may provide different advice than DAD does on this subject, or no advice at all in some cases.
The goal of the first blog posting in this series is to address several potential misconceptions that appeared in the email. I want to start here so as to lay a sensible foundation for the follow-on postings.
Partial Misconception #1: Agile can be prefixed in iteration 0 by architectural design
I’ve named this a “partial misconception” for a few reasons:
Partial Misconception #2: On principle, Agile is against “big” anything
This is also a “partial misconception” for several reasons:
Partial Misconception #3: Refactoring system architecture beyond mid-implementation is much more expensive than refactoring components
Once again, this is a partial misconception. I suspect part of the problem is a lack of understanding of what refactoring is really all about, a recurring problem with experienced traditionalists, and part because of a lack of understanding of how architecture is address by disciplined agile teams. Some thoughts:
In short, disciplined agile teams do what they can to avoid architectural rework to begin with by having an explicit architecture owner role who focuses on architectural issues throughout the entire lifecycle, by identifying a viable architectural strategy early in the project, proving that architectural strategy works early in Construction, and producing high-quality artifacts throughout the lifecycle that are easier to rework if needed. With continuous documentation practices and a focus on producing artifacts which are just sufficient enough for the situation at hand, this proves to be far more effective than traditional strategies that assume you require large up-front investments in “big” artifacts, that rely on validation techniques such as architecture reviews instead of the far more concrete feedback of working code, and that often leave quality strategies to the end of the lifecycle (thereby increasing the cost of any rework).
I plan two follow-on blog postings in this series, one exploring how initial architecture envisioning works and one about how to address initial quality requirements (also called non-functional requirements or quality of service requirements) on disciplined agile projects. Stay tuned!
At Scott W. Ambler + Associates we offer a one-day workshop entitled Agile Architecture: A Disciplined Approach that you should consider if you’re interested in this topic. We also offer coaching and mentoring services around agile architecture.