Category Archives: Construction phase

Move Closer to a Deployable Release

One of the process goals that a disciplined agile team will want to address during construction is Move Closer to a Deployable Release.  Ideally, in each construction iteration a team will move closer to having a version of their solution that provides sufficient functionality to its stakeholders.  This implies that the solution is a minimally viable product (MVP) that adds greater business value than its cost to develop and deploy.  Realistically it isn’t a perfect world and sometimes a team will run into a bit of trouble resulting in an iteration where they may not have moved closer to something deployable but hopefully they’ve at least learned from their experiences.

Move closer to a deployable release is an important process goal for several 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.

The process goal diagram Move Closer to a Deployable Release is shown below. The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues. The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom. The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now. Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.
Move Closer to a Deployable Release

Let’s consider each process factor:

  • Choose a Deployment Strategy.  Deployment can be a struggle for teams new to agile.  Many teams will start by aiming to deploy their solution into production more regularly, perhaps every few months instead of every six to twelve months.  Then they will start deploying working builds internally at the end of each iteration, perhaps into demo or testing environments.  Finally they will hopefully evolve into a continuous deployment (CD) strategy.
  • Manage Assets.  The issue here is how your team will manage the various artifacts, including code, which they use and create while building a solution.  Sadly we’ve found that some teams still struggle with basic configuration management control.  Although they may have their source code under fairly sophisticated control other artifacts such as supporting documentation often aren’t.
  • Document.  Supporting documentation, such as user guides and system overviews, are part of the overall solution that the team is working on.  The DAD framework leverages strategies from Agile Modeling to address this process factor.  Your team may choose to leave such documentation to the end of the lifecycle or to write documentation throughout the lifecycle.
  • Plan Deployment.  There are several techniques that you may want to consider for deployment planning, an important aspect of your overall DevOps strategy.  Although some teams may begin such planning with their operations/release engineers late in the lifecycle, many will instead plan throughout the lifecycle.  The DAD framework recognizes operations staff as key stakeholders, people whom you will actively work with to plan and then deploy your solution.
  • Maintain Traceability.  Traceability from requirements through your design to your code to your tests, or a subset thereof, may be required by your team.  This is common for some, but not all, regulations.  Traceability is often perceived as critical to enable impact analysis, although in practice this is questionable as manually maintained traceability matrices are rarely kept up to date.
  • Validate.  DAD captures the fact that there are many ways that you can choose to validate your work, including a range of agile quality techniques (TDD, CI, ATDD/BDD) and even a few that are not-so-agile (end-of-lifecycle testing, manual testing, parallel independent testing).  The DAD framework purposely includes these not-so-agile strategies because in some situations, particularly at scale, they may in fact be your best options.  Furthermore, your team may be in the early stages of becoming agile and as a result then not-so-agile strategies may be the best they are currently capable of doing.
  • Verify.  DAD also recommends that you consider verification strategies to help increase the quality of your work. These strategies include reviews, non-solo development strategies such as pair programming and modeling with others (which are effectively continuous reviews), and including code analysis tools in your CI strategy.

We want to share two important observations about this goal.  First, this goal, along with Explore Initial ScopeCoordinate Activities, and Identify Initial Technical Strategy seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  As you saw in the discussion of the process issues, the process tailoring decisions that you make regarding this goal will vary greatly based on the various scaling factors.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

We’re firm believers that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own.  The DAD process decision framework provides this guidance.

Comparing DAD to the Rational Unified Process (RUP) – Part 2

This post is a follow-up to Comparing DAD to the Rational Unified Process (RUP) – Part 1.  In that post I described in some detail why Disciplined Agile Delivery (DAD) is not “Agile RUP”.  DAD is quite different in both approach and content.  There are however some very good principles that the Unified Process (UP) incorporates that are not part of mainstream agile methods.  This post describes what parts of the UP made it into the DAD process decision framework.

DAD suggests a full delivery lifecycle approach similar to RUP.  DAD recognizes that despite some agile rhetoric projects do indeed go through specific phases.  RUP explicitly has four phases for Inception, Elaboration, Construction, and Transition.  For reasons that I described in the last post, DAD does not include an explicit Elaboration phase.  However the milestone for Elaboration is still in DAD which I will describe shortly.  As the DAD basic lifecycle diagram shows, DAD has three of the four RUP phases.

Disciplined Agile Lifecycle Basic

  • The Inception phase.  An important aspect  of DAD is its explicit inclusion of an Inception phase where project initiation activities occur.  As Scott Ambler says in one of his posts “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 the general perception (the 2009 Agile Project Initiation survey  found the average agile team spends 3.9 weeks in Inception)”.  So in DAD’s Inception phase (usually one iteration) we do some very lightweight visioning activities to properly frame the project.  The milestone for this phase is to obtain “Stakeholder consensus” on how to proceed.  In the book we describe various strategies to get through the Inception phase as quickly as possible, what needs to be done, and how to get stakeholders consensus.
  • The Construction phase.  This phase can be viewed as a set of iterations (Sprints in Scrum parlance) to build increments of the solution.  Within each iteration the team applies a hybrid of practices from Scrum, XP, Agile modeling, Agile data, and other methods to deliver the solution.  DAD recommends a risk-value approach of prioritizing work in the early iterations which draws from the RUP principle of mitigating risk as early as possible in the project by proving the architecture with a working solution.  We therefore balance delivering high-value work with delivering work related to mitigating these architectural risks.  Ideally we deliver stories/features in the early iteration that deliver functionality related to both high business value and risk mitigation (hence DAD’s “risk-value” lifecycle). It is worthwhile to have a checkpoint at the end of the early iterations to verify that indeed our technical risks have been addressed.  DAD has an explicit milestone for this called “Proven architecture”.  This is similar to the RUP Elaboration milestone without risking the confusion that the Elaboration phase often caused for RUP implementations.  All agile methods seek to deliver value into the hands of the stakeholders as quickly as possible.  In many if not most large enterprises it is difficult to actually deliver new increments of the solution at the end of each iteration.  DAD therefore recognizes this reality and assumes that in most cases there will be a number of iterations of Construction before the solution is actually deployed to the customer.  As we make clear in the book, although this is the classic DAD pattern, you should strive to be able to release your solution on a much more frequent basis in the spirit of  achieving the goal of “continuous delivery”.  The milestone for the end of Construction is that we have “Sufficient functionality” to deploy to the stakeholders.  This is the same milestone as the RUP’s Construction milestone.  During the Construction phase it may make sense to periodically review the progress of the project against the vision agreed to in Inception and potentially adjust course.  These optional milestones in DAD are referred to as “Project viability”.
  • The Transition phase.  DAD recognizes that for sophisticated enterprise agile projects often deploying the solution to the stakeholders is not a trivial exercise.  To account for this reality DAD incorporates the RUP Transition phase which is usually one short iteration.  As DAD teams, as well as the enterprise overall streamline their deployment processes this phase should become shorter and ideally disappear over time as continuous deployment becomes possible.  RUP’s Transition milestone is achieved when the customer is satisfied and self-sufficient.  DAD changes this to “Delighted stakeholders”.  This is similar to lean’s delighted customers but we recognize that in an enterprise there are more stakeholders to delight than just customers, such as production support for instance.  One aspect of RUP’s Transition phase is that it is not clear on when during the phase deployments actually take place.  Clearly stakeholders aren’t delighted and satisfied the day the solution goes “live”.  There is usually a period of stabilization, tuning, training etc. before the stakeholders are completely happy.  So DAD has a mid-Transition milestone called “Production ready”.  Some people formalize this as a “go/no go” decision.

So in summary, DAD frames an agile project within the context of an end-to-end risk-value lifecycle with specific milestones to ensure that the project is progressing appropriately.  These checkpoints give specific opportunities to change course, adapt, and progress into the next phases of the project.  While the lifecycle is similar to that of RUP, as described in Part 1 of this post it is important to realize that the actual work performed within the iterations is quite different and far more agile than a typical RUP project.

At Scott Ambler + Associates we are getting a lot of inquiries from companies seeking help to move from RUP to the more agile yet disciplined approach that DAD provides.

Strategies for Implementing Non-Functional Requirements

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.

Chapter 8 in the Disciplined Agile Delivery book, written by Mark Lines and myself, overviews several strategies for capturing and then implementing 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:

  1. Technical stories.  A technical story is a documentation strategy where the NFR is captured as a separate entity that is meant to be addressed in a single iteration.  Technical stories are in effect the NFR equivalent of a user story. For example “The system will be unavailable to end users no more than 30 seconds a week” and “Only the employee, their direct manager, and manager-level human resource people have access to salary information about said employee” are both examples of technical stories.
  2. Acceptance criteria for individual functional requirements.  Part of the strategy of ensuring that a work item is done at the end of an iteration is to verify that it meets all of its acceptance criteria.  Many of these acceptance criterions will reflect NFRs specific to an individual usage requirement, such as “Salary information read-only accessible by the employee,”, “Salary information read-only accessible by their direct manager”, “Salary information read/write accessible by HR managers”, and “Salary information is not accessible to anyone without specific access rights”.  So in effect NFRs are implemented because they become part of your “done” criteria.
  3. Explicit list.  Capture NFRs separately from your work item list in a separate artifact.  This provides you with a reminder for the issues to consider when formulating acceptance criteria for your functional requirements.  In the Unified Process this artifact was called a supplementary specification.

Of course a fourth option would be to not capture NFRs at all.  In theory I suppose this would work in very simple situations but it clearly runs a significant risk of the team building a solution that doesn’t meet the operational needs of the stakeholders.  This is often a symptom of a teams only working with a small subset of their stakeholder types (e.g. only working with end users but not operations staff, senior managers, and so on)

So what are the implications for implementing NFRs given the three previous capture strategies?    Although in the book we would 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:

  1. Technical stories.  The advantages of this approach are that it is a simple strategy for capturing NFRs and that it works well for solutions with a few NFRs or simple NFRs.  But, the vast majority of NFRs are cross-cutting aspects to several functional stories and as a result cannot be implemented within a single iteration.  This strategy also runs the risk of teams leaving NFRs to the end of the construction phase, thereby pushing technical risk to the end of the lifecycle where it is most difficult and expensive to address.
  2. Acceptance criteria. This is a quality focused approach which makes the complexity of an individual functional requirement apparent, working well with test driven approaches to development.  NFR details are typically identified on a just in time (JIT) basis during construction, fitting in well with a disciplined agile approach.  But, because many NFRs are cross cutting the same NFR will be captured for many functional requirements.  It requires the team to remember and consider all potential NFR issues (see Figure in my previous posting) for each functional requirement.  You will still need to consider NFRs as part of your initial architecture efforts otherwise you risk a major rework effort during the Construction phase because you missed a critical cross-cutting concern).
  3. Explicit list.  This strategy enables you to explore NFRs early in the lifecycle and then address them in your architecture.  The list can be used to drive identification of acceptance criteria on a JIT basis.  But, NFR documents can become long for complex systems (due to the large number of NFRs).  This can be particularly problematic when you have a lot of NFRs that are specific to a small number of functional requirements.  Teams lacking in discipline may not write down the non-functional requirements and trust that they will remember to address them when they’re identifying acceptance criteria for individual stories.

 

The advice that Mark and I give in the book is that 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.

In my next blog posting, the fourth in this three-part series, I will describe strategies for verifying non-functional requirements.