Disciplined Agile Delivery (DAD) is a hybrid framework that builds upon the solid foundation of other methods and software process frameworks. The DA toolkit adopts practices and strategies from existing sources and provides advice for when and how to apply them together. In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.
The DA toolkit adopts strategies from the following sources:
One of the great advantages of agile and lean software development is the wealth of practices, techniques, and strategies available to you. This is also one of its greatest challenges because without something like DAD it’s difficult to know what to choose and how to fit them together.
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.