Disciplined Agile

There are several disaster mitigation strategies that IT departments may choose to adopt:

1. Disaster planning. Disciplined organizations will plan for operational disasters. Potential disasters include servers going down, network connectivity going down, power outages, failed solution deployments, failed infrastructure deployments, natural disasters such as fires and floods, terrorist attacks, and many more. This planning will include identification of potential problems, identification of strategies to address those problems, and putting mechanisms in place to hopefully mitigate the disasters. Potential strategies to address these disasters include building solutions that self-test and self-recover, building redundancies into your operational infrastructure, having disaster procedures in place, and practicing those procedures in simulated disasters.
2. Scheduled disaster simulation. It is one thing to have disaster mitigations plans in place, it is another to know whether they actually work. Disciplined organizations will run through disaster scenarios to verify how well their mitigation strategies work in practice. For example, to test whether your power outage emergency plan works you would purposely simulate a power outage at one of your data centers and then work through your recovery plan. Like fire drills, these simulations should be done on a regular basis so that staff members build up the “body memory” required to act swiftly and appropriately in an emergency. The advantage of a scheduled disaster simulation is that you knowingly run it at a time where you will have minimal impact on your stakeholders.   A disadvantage, at least when people are informed of the simulation ahead of time, is that people are mentally prepared for the simulation and aren’t caught unaware and thereby you don’t simulate the real level of stress that people would be under during an actual emergency.
3. Random disaster simulation. Very disciplined organizations will implement a service within their operational environment that causes problems such as server or service outages at random times. An example of this is the Chaos Monkey functionality in Amazon’s Web Services (AWS) offering, functionality that is being implemented within many organizations now. The Chaos Monkey injects random problems into production to verify that the IT operations organization is capable of overcoming them. This is done to verify that your solutions really are able to automatically recover from problems and failing that at least operators are alerted to the problem.

As you would expect, truly disciplined organizations have adopted all of these strategies.

Related blog postings:

• Defining Disciplined DevOps
• DevOps Strategies: General

DAD incorporates a number of milestones into its lifecycles to gauge the progress and health of your DAD projects/releases.

Why does DAD have milestones?

Governance is largely absent from mainstream agile methods and many believe that agile does not need milestones.   Scrum orders its backlog with highest value work at the top of the stack.  At the end of each sprint (iteration) a decision is intended to be made whether or not the next sprint of work in the backlog provides sufficient value to fund another sprint.  If not, the project stops.  While in principle this strategy makes sense, as a replacement for governance it is flawed for several reasons:

• Not sufficient.  There is much more to effective governance than deciding when to cease the funding of a project.  How did it get started in the first place for instance?
• Not realistic.  In reality most organizations tend to fund releases comprised of many iterations rather than make explicit funding decisions at the end of each sprint.
• Effectively a milestone.  While Scrum claims to not have milestones, pausing to consider if sufficient functionality exists to deploy, and to determine a go-forward strategy is implicitly a milestone.  DAD makes them explicit with guidance for how to effectively apply them.

Why do we need agile governance?

Contrary to what many believe, the need for governance does not disappear for agile initiatives.  Sponsors and other stakeholders deserve and indeed demand periodic updates on the status of their investments.  They want answers to questions like:

• What will I get from my investment and will it be worthwhile?
• Is what is being delivered consistent with the initial funding request?
• What is the status of the outstanding risks and what is being done to mitigate them?
• Is the current release timeline consistent with the original projection?
• When will we have sufficient functionality to go live?
• Are all stakeholders prepared to receive the release?
• When will the project be finished?

Claims that agile is “different” and does not need to provide these answers is one of the reasons that agile is sometimes seen as being undisciplined.  In fact these claims are often used by some as an excuse why agile won’t work for them.  Fortunately, since DAD has built in mechanisms to facilitate answering these questions many organizations are extending their agile implementations to incorporate DAD’s guidance.  Indeed DAD is very appealing to those looking for a way to govern projects while still remaining agile.

Milestone Reviews Should Be Kept Informal

Consistent with the strategy recommended in the DAD goal Govern Delivery Team, milestone reviews should be done in a light manner.  They typically coincide with the end of iterations or phases when when using the Agile/Basic lifecycle.  If you are unsure why DAD has phases you might find the blog posting on the rationale interesting.

Milestone Dates Should Be Communicated

It is a good practice to provide a calendar to stakeholders with milestone dates for each DAD project so that they can plan to attend iteration reviews that coincide with milestone reviews that they are interested in.  While milestone dates may change, it is very useful to have target milestones across a portfolio of projects visible as a roadmap to all stakeholders.

The DAD Milestones

Stakeholder Vision.  The goal of the Inception phase is to spend a short yet sufficient amount of time, typically one to four weeks in order gain stakeholder agreement that the initiative makes sense and to therefore continue into the Construction phase.  By addressing each of the DAD Inception goals the delivery team will capture traditional project information related to initial scope, technology, schedule, budget, risks, and other information albeit in as lightweight a fashion as possible.  This information is consolidated and presented to stakeholders as a Vision statement as described by the Develop Common Vision goal.  The format of the vision and formality of review with vary according to your situation.  A typical practice is to review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page with regard to the project intent and delivery approach.

Proven Architecture.  Early risk mitigation on a project is a part of any good project management discipline.  As the Prove Architecture Early process goal indicates, there are several strategies you may choose to adopt to do so.  The most effective of which is to build an end-to-end skeleton of working code that implements technically risky business requirements.  A key responsibility of DAD’s Architecture Owner role is to identify risks in the Inception phase.  It is expected that these risks will have been reduced or eliminated by implementing related functionality somewhere between one and three iterations into the Construction phase.  As a result of applying this approach early iteration reviews/demos often show the ability of the solution to support non-functional requirements in addition to, or instead of functional requirements.  For this reason it is important that architecture related stakeholders are given the opportunity to participate in these milestone reviews.

Continued Viability.  An optional milestone to include in your release schedule is related to project viability.  At certain times during the project stakeholders may request a checkpoint to ensure that the project is progressing consistent with the vision agreed to at the end of Inception.  Scheduling these milestones ensures that stakeholders are aware of key dates wherein they should get together with the team to assess the project status and agree to changes if necessary.  These changes could include anything such as funding levels, team makeup, scope, risk assessment, or even potentially cancelling the project.  There could be several of these milestones.  If the stakeholders agree to changes the Vision may be updated at this time.  Scrum implicitly has this milestone at the end of each sprint.  DAD makes this an explicit choice and makes it’s frequency optional.

Sufficient Functionality.  While it is worthwhile pursuing a goal of a consumable solution (what Scrum calls a potentially shippable increment) at the end of each iteration, it is more common to require a number of iterations of Construction before the team has implemented enough functionality to deploy.  While this is sometimes referred to as a minimally viable product (MVP) this not technically accurate as classically an MVP is meant to test the viability of a product rather than an indication of minimal deployable functionality.  The more accurate term to compare to this milestone would be “minimum feature set”.  Regardless, many use the acronym to mean the latter.

DAD’s sufficient functionality milestone is reached at the end of the Construction phase when a sufficient functionality is available plus the cost of transitioning the release to stakeholders is justified.  As an example, while an increment of a consumable solution may be available every two week iteration, it may take two weeks to actually deploy it in a high compliance environment so the cost of transitioning the functionality may not be justified until a greater amount of functionality is completed.

Production Ready.  For non-trivial situations a formal Transition phase is often required to do final preparations as part of delivery of the solution to stakeholders.  Once sufficient functionality has been developed and tested, transition related activities such as data conversions, final acceptance testing, production and support related documentation normally need to be completed. Ideally much of the work has been done continuously during the Construction phase as part of completing each increment of functionality. At some point a decision needs to be made that the solution is ready for production.  Of course, if you’re following the continuous delivery lifecycle then the “Transition phase” has evolved into a “Transition activity” – regardless, someone still needs to ensure that the solution is consumable before you deploy the solution.

Delighted Stakeholders.  Governance bodies and other stakeholders obviously like to know when the initiative is officially over so that they can begin another release or direct funds elsewhere.  The initiative doesn’t end the day after deploying a solution to stakeholders.  There are often project closeout activities such as training, deployment tuning, support handoffs, post implementation reviews, or even warranty periods before the project is considered completed.  Lean has a term “delighted customers” which suggests that “satisfied” customers is setting the bar too low.  While DAD agrees, there are more stakeholders than just customers such as production support that we need to delight before we consider the project complete, thus the milestone name “delighted stakeholders”.

Give Milestones a Try

Agile promotes transparency and accountability to our stakeholders.  Take this to the next level by sharing and celebrating achievement of key milestones on your projects.

We’ve recently been asked how risk management is addressed on agile teams. This is an easy question to answer because risk management strategies are built right into the Disciplined Agile (DA) toolkit.

Let’s start with two definitions. First, a risk is an exposure to a potentially negative outcome. Risks come about from uncertainty. Second, risk management is the identification, exploration, and mitigation of risks. Risk management should be part of both your team management efforts, even on self-organizing agile teams, as well as part of your organizations governance efforts.

Regardless of your delivery paradigm, there are several common categories of risks faced by IT delivery teams:

• Business risk. This includes significant shifts in requirements due changing business priorities, often due to realization new market opportunities, in reaction to moves made by competitors, or because you are opening completely new market opportunities. Another common risk is an overly optimistic/aggressive schedule which motivates your team to take unfortunate shortcuts. A third type of business risk is a misaligned budget: either there isn’t sufficient funding to do the job effectively (e.g. there’s no travel budget for a geographically distributed team, there’s no funding for coaching on a team new to agile, there’s no funding for training, and so on) or there is far too much funding available and the team is motivated to invest it in wasteful activities.
• Technical risk. IT teams face technical risks as the result of combining technologies in new ways, evolving technology platforms, new technologies, and lack of experience within the team in these situations.
• Operational risk. This category of risk pertains to production-oriented issues surrounding the support and operation of a solution. Will your solution work within the existing organizational ecosystem? Does your operations team have the skills and resources to run your solution? Does your support/help desk team have the experience and knowledge required?
• Process risk. As DAD clearly shows, every technique has advantages, disadvantages, and specific situations where the technique makes sense. The implication is that there are risks taken on when you apply a technique outside of its range of applicability or your comfort zone.
• Organizational risk. IT teams face organizational risks such as dysfunctional politics, competing visions, challenges pertaining to your agile transformation challenges, reorganizations, and many others.

Recognizing that IT delivery teams must deal with risks on a regular basis DAD builds in several agile risk management strategies:

• Continuous engineering practices.  This is a collection of practices with very short feedback cycles, thereby enabling you to adjust course quickly. These practices include behavior driven development (BDD), test-driven development (TDD), continuous integration (CI), continuous deployment (CD), and many others.  All of these practices require discipline and skill to adopt.  Although these practices are technical in nature, in practice they mostly reduce business risk through shortening the cycle between a stakeholder having an initial idea and the team providing a solution which reflects that idea.
• Agile architecture practices.  The DA toolkit suggests a collection of continuous architecture strategies throughout the entire lifecycle.  These include, but are not limited to, identifying an initial technical strategy, proving the architecture early in construction, deferring architecture and design decisions to the most appropriate moment, architecture spikes, just in time (JIT) model storming, and many others.  These practices reduce technical risk.
• Risk-value lifecycle.  The DA toolkit supports several lifecycles, and hence several work prioritization strategies.  One such strategy is the Unified Process (UP)’s risk-value approach where both risk and value are considered when prioritizing work items.  The end result is that work items with higher technical risk are implemented early in the lifecycle, enabling disciplined agile teams to mitigate technical risk early in the effort.  DAD teams then follow Scrum’s value-driven approach where the work is prioritized based on its business value to the organization, which is effective at addressing some forms of business risk.  The risk-value prioritization approach results in a lower overall risk profile than just the value-driven lifecycle of Scrum.  DAD also supports lean and continuous delivery versions of the lifecycle which expand upon the risk-value strategy to consider other factors such as required release dates and team health considerations.
• An explicit Inception phase.  The fundamental purpose of the Inception phase is to help your team get going in the right direction.  Executed properly, the Inception phase helps you to reduce business risk by coming to stakeholder agreement regarding the team’s strategy, technical risk by exploring a viable technical strategy, and operational risk through planning with production-staff from the very beginning.
• Risk-based, light-weight milestones.  The DAD lifecycles include explicit milestones as part of DAD’s overall governance strategy.  These milestones motivate teams to address common issues such as formulating an agreed-to vision early in the effort (business risk), proving the architecture early (technical risk), regularly considering the viability of the effort (business risk), ensuring the team has produced sufficient functionality to justify deployment (business risk), ensuring the solution is production ready (operational risk), and ensuring that the stakeholders are delighted with the result (business risk, organizational risk).
• Development intelligence.  One of the governance strategies that the DAD process framework promotes is development intelligence (DI) where a team/project dashboard is populated with metrics generated automatically by the tools the team is using.  This provides real-time insight for the team to organize itself and potentially improve its approach.  It also provides insight into your organization’s governance effort, supplying real-time data which can enable senior management to make better decisions and thereby better support your agile teams.  Development intelligence, and it’s extension IT intelligence which addresses the entire IT portfolio and processes, helps you to reduce process risk and to a lesser extent organizational risk.
• DevOps principles and practices. DAD weaves DevOps strategies through the entire framework.  This strategies are: Including operations and support staff as explicit stakeholders who work closely with the team; the lifecycle explicitly depicts production/operations; DevOps-oriented milestones (Production Ready and Delighted Stakeholders) are included as part of the governance strategy; development practices such as instrumenting solutions for operational monitoring, continuous deployment, and installation testing (to name a few); and management practices such as deployment planning. The strategies help to reduce both operational and organizational risks.
• Sophisticated go-forward decision points.  One of the business risk management strategies promoted by Scrum and RUP is to make a “go/no-go” decision at the end of each sprint/iteration.   DAD takes this strategy further by recognizing that you have several options to consider – your team can continue with its current approach (go), it can stop (no-go), it can decide to change direction (pivot), or it can decide to experiment (run a split test).  The two new options are adopted from Lean Startup. DAD’s lean and continuous delivery lifecycles promote the idea that you make these go forward decisions when you need to, that you don’t need to wait until the end of an iteration to do so.
• Risk-oriented process goal.  The DA toolkit promotes a non-prescriptive, process goal-driven approach.  DAD explicitly includes a goal, Address Risk, the goal diagram for which is presented below in Figure 1.

Figure 1. The Address Risk process goal.

• IT risk management is built in. IT-level risk management is built into the IT Governance process blade.  Although a risk may be small for a single team, when that same risk is taken by multiple teams in parallel in aggregate the risk may be more than your organization should take on.  Hence your risk management efforts at the delivery team level must be monitored regularly and aggregate risks mitigated appropriately. The process goal diagram for IT governance is shown below in Figure 2.

Figure 2. IT-risk management is an aspect of IT Governance.

Risk management isn’t explicitly built into first generation agile methodologies like Scrum or XP, although a handful of implicit risk mitigation techniques are.  As a result you still need to develop a risk management strategy for yourself when you limit your team to these sorts of agile methods.  The DA toolkit, on the other hand, has built risk management strategies into the toolkit in a lightweight and comprehensive manner.  From the point of view of process risk, having such guidance built into your process is a low-risk and desirable approach.  For further reading about risk management, we highly suggest the list of references maintained by Glen B. Alleman.