CAREFULLY CONSIDER “AGILE BUSINESS CONTINUITY”

Many business executives are asking those responsible for business continuity – and the managers of other disciplines as well – “Should we implement Agile in our program?”
It’s a fair question, but can an organization fully apply Agile principles to business continuity and achieve the right level of resiliency while also achieving higher levels of efficiency and effectiveness?

We will examine these questions in this blog and how Agile has the potential to improve business continuity outcomes. With that said, this article is simply meant to spur discussion on the topic of Agile outside of application development. It IS NOT intended to be the definitive answer as to how to apply Agile to business continuity.
I think it’s important to start this blog with an Agile introduction to ensure we’re all on the same page.

First, the intent of Agile is to align work (often application development-related work) with business needs. When done well, Agile projects are more customer-focused and encourage feedback and customer participation. At Riskonnect, we use Agile successfully in the development and continual improvement of our business continuity software system, Riskonnect.

Second, there are many different “flavors” of Agile – with Scrum and Kanban being two popular implementation methods. But regardless of what flavor an organization employs, Agile is simply a set of values and principles at its core – some of which may apply nicely to business continuity, whereas others might be more of a stretch. Many of these values and principles – which I will introduce in a moment – align with Riskonnect’s Business Continuity Operating SystemTM (BCOS). So here’s the punch line – Agile has the promise to provide significant value to your organization and its business continuity program (but allow me to explain why in this blog). Of note, as you review the list of Agile values and principles below, simply replace the word “software” with “business continuity”.

Agile Values Overview and Conclusions

Regardless of the “flavor”, Agile has four fundamental “values,” and here’s my interpretation of each…

1. Working Software Over Comprehensive Documentation – Obsess about building capability rather than design documentation and specifications.
2. Customer Collaboration over Contract Negotiations – Work together on the best solution rather than focusing on administrative issues, political barriers, and boundaries.
3. Responding to Change Over Following a Plan – Having an approach is great but be positioned to adapt your approach as you learn.
4. Individuals and Interactions over Process and Tools – Engagement in solving a problem is key.

The following graphic summarizes how I view the benefit of the four Agile values as it applies to business continuity.

Why these conclusions?

First, specific to Working Software Over Comprehensive Documentation, I see some benefit to the business continuity profession, but of the four, it’s probably the least impactful. Earlier in the blog, I mentioned how I think quite a bit of Agile aligns with Riskonnect’s BCOS approach. BCOS advocates process documentation “followed by all”. I admit that process and process documentation is simply a means to an end. But a process that key stakeholders understand and can participate in is necessary to get to the real end, “working response/recovery capability”.

Second, specific to Customer Collaboration Over Contract Negotiation, I see value regarding collaboration. Some Agile critics often interpret this value as avoiding commitment, meaning a lack of commitment to a timeline to meet an expectation. More accurately though, this value actually means that Agile should more appropriately be focused on innovation and evolution to get to the best solution. To me, collaboration is key and results in an agreement on goals, priorities, and requirements. In many ways, the “traditional” business continuity methodology, as described in ISO 22301, already advocates leadership and process owner engagement, as well as engagement of other necessary stakeholders. In reality, many programs fail to emphasize a risk-based focus and stakeholder engagement, and collaboration with the business customer isn’t always intentional. More on this in a moment when we get into the Agile “principles”.

Third, specific to Responding to Change Over Following a Plan, I see the benefit when we pair this value with traditional business continuity best practice by adding “Agileness” to response and recovery plans. In my opinion, plans are a useful business continuity planning process outcome in that they capture information that’s hard to memorize, may not always be intuitive, and services as guidance – or reminders – on how to manage the response to a disruption.

Lastly, specific to Individuals and Interactions Over Processes and Tools, I see a lot of benefits here, as engagement is a key success factor in high functioning business continuity programs that deliver resilience. Unfortunately, traditional business continuity planning thinking is mostly about executing methodology, with participant engagement being a secondary consideration. As noted in Riskonnect’s BCOS model, a “documented process followed by all” is extremely important, but when paired with great engagement among program participants at its foundation, the organization is far better positioned to achieve the right level of resiliency. With this in mind, I would change this value’s title to “Individuals and Interactions with Processes and Tools” (if I could).

Agile Principles Overview and Conclusions

Agile has 12 fundamental principles that traditionally deliver software development benefits, and some can add benefit when applied to business continuity.

1. Customer satisfaction through early and continuous software delivery – Deliver, innovate, deliver, innovate, deliver innovate (and so on); create capability, test it, and improve (but don’t wait for perfection before delivering).
2. Accommodate changing requirements throughout the development process – Collect feedback all the time and apply it in a prioritized manner.
3. Frequent delivery of working software – For example, don’t wait for the “once-a-year” strategy phase to complete before improving response and recovery capability; deliver business continuity capability continuously.
4. Collaboration between the business stakeholders and developers throughout the project – Stay engaged with the business (including process and resource owners) and partner with them to develop and maintain response and recovery capabilities.
5. Support, trust, and motivate the people involved – Understand what the business cares about when it comes to business continuity and make sure the focus, capability, and engagement align (and trust that the business will do the right thing in helping you to execute the business continuity program).
6. Enable face-to-face interactions – In a perfect world, sure…. See below for more on this one!
7. Working software is the primary measure of progress – In business continuity speak, a response or recovery capability more than methodology and plans.
8. Agile processes to support a consistent development pace – Consistent pace may not be applicable, or add a lot of value, to business continuity.
9. Attention to technical detail and design enhances agility – Indirectly, this is a key principle, which ensures program participants have the time and competencies to perform their roles.
10. Simplicity – YES! Keep it simple (remove unnecessary complexity) and make it easy for the organization to participate in the business continuity program.
11. Self-organizing teams encourage great architectures, requirements, and designs – Specific to business continuity, I see this principle encouraging low-risk experiments to drive program efficiency and effectiveness.
12. Regular reflections on how to become more effective – Engagement, evaluate performance, process issues, and improve (specific to the business continuity program and response/recovery capabilities).

The following graphic summarizes how I view the benefit associated with each of the Agile principles as it applies to business continuity.

Why these conclusions?

1. Customer satisfaction through early and continuous software delivery – Some practitioners work to address the “low hanging fruit” while at the same time tackling “meatier” issues, but many programs wait to the conclusion of a planning cycle when it’s time to select strategies (which is essentially methodology over risk mitigation). Through great and continuous engagement, the solution often becomes obvious fast. As such, it quickly establishes a short-term to-do or longer-term action or goal to achieve higher levels of capability.
2. Accommodate changing requirements throughout the development process – Traditional business continuity is ever-green in that there is widespread recognition that you’re never done, and business continuity outcomes will change as the organization changes. This principle certainly aligns with best practice but remember to innovate and evolve continuously.
3. Frequent delivery of working software – There’s some value to be had here, and in many ways, Riskonnect bakes this principle into the BCOS. It starts with a focus on what’s most important and then continues by using two-week, quarterly, annual and three-year work cycles (inclusive of goals and targets) to deliver improving response and recovery capability.
4. Collaboration between the business stakeholders and developers throughout the project – There’s a significant potential benefit here because of the focus on productive engagement with all stakeholders, including senior leadership through those performing the work.
5. Support, trust, and motivate the people involved – This principle is so important. Unfortunately, it really isn’t fully addressed in business continuity standards and best practices. All too often, business continuity professionals demand business participation but restrict participants (“box them in”) due to a lack of trust that they will do the right thing. Ultimately, business continuity professionals should work hard to motivate program participants (involving people that want to participate and helping them connect to the importance of business continuity), instill high energy and effective engagement with program participants, trust they’ll do the right thing if trained appropriately, and focus on measuring and improving.
6. Enable face-to-face interactions – Simply put, I don’t see this as “business reality” in today’s global and mobile work environment. But when you can get face time, it makes engagement easier. And there’s always video conferencing…
7. Working software is the primary measure of progress – Too often we measure and value how we get to business continuity solutions and strategies, with the actual resiliency capability being an afterthought. The eternal BCOS objective is “the right level of resilience”, which is essentially the equivalent of “working software”. I see this principle as the most valuable of them all.
8. Agile processes to support a consistent development pace – I think we can omit this principle; the consistent pace is not as important as a risk-based pace.
9. Attention to technical detail and design enhances agility – As mentioned earlier, I see this principle aligning to something valuable, program participant competencies and experiences being key.
10. Simplicity – My most common observation in our discipline is entirely too much unnecessary program complexity because many traditional business continuity planning practices lack pragmatism.
11. Self-organizing teams encourage great architectures, requirements, and designs – There’s some value to be had here. Don’t stifle those that truly want to proactively participate to advance the program and the organization’s capability to respond and recover. At the same time, remember to seek input and/or approval from the right people in your quest to improve and achieve the right level of resilience.
12. Regular reflections on how to become more effective – The last of the valuable Agile principles. Standards and best practices address topics such as corrective actions, post-incident reviews, and management reviews but often fail to help explain how to achieve maximum value. Engage the right people at the right frequency with information that motivates. And in meetings and other interactions, “process” performance issues, which involves solving for the root cause of performance issues or other opportunities for improvement.

Conclusions

When someone asks you to apply Agile to business continuity, ask them if they are mixing up the values and principles with a flavor of Agile as noted above, such as Scrum or Kanban. In my opinion, the Scrum approach may be more value-adding for business continuity and aligns with many of Riskonnect’s BCOS attributes (like two-week increment to-do’s found in Evolve), foundational ingredients (like Engage), and core processes (like Evolve). Kanban might be much harder to extract value within business continuity given its focus on minimizing work-in-progress.

Overall, here’s a question. Are accountants being asked to do Agile Accounting? Agile HR? Agile Compliance? Just because it works in IT, doesn’t mean it should fully apply to everyone, and it’s certainly not a one-size-fits-all. Perhaps instead of defaulting to considering a flavor of Agile, consider instead leveraging select Agile values and principles to help achieve the right level of resiliency through program focus and engagement with the right people in your organization.