Organizations can never be 100 percent agile, at least according to the textbook definition. Most companies must follow some business processes with inflexible requirements and prescribed deliverables that are tied to specific dates. Some of these processes are imposed by law. And for the executive focused on expanding business agility across the enterprise, rigid requirements dictated by forces outside company walls can seem like a blocker. Regardless, if you want to do business in some of the largest markets in the world, you have to comply.
But agile practices can be applied to auditing and regulatory compliance processes – even those that involve multiple departments and the attention of many people. And instead of a distraction, these efforts can build the muscles organizations need to stay competitive.
Here’s why: agile organizations that embrace the spirit of agile (i.e., agile without rigidity) can break down silos and create cross-functional and multidisciplinary teams that have the freedom to innovate. The agile approach fosters better communication and collaboration, allowing teams to cross-pollinate and develop new skill sets.
Companies that extend their agile transformation into their most rigid business processes have better business outcomes. In fact, a recent report by McKinsey found that organizations that successfully complete an agile transformation see a 30-50 percent improvement in operational performance.
Success depends on a leader who guides with agility
In my years as an inventor and co-creator of some innovative technologies, and as an agile transformation leader, I’ve seen organizations expand the success of their agile development teams to the connected business processes with great results.
The one constant in these successes is a leader who understands agile principles and is adept at applying the spirit of agile to enterprise business processes. Thee know that agile itself is not about what you do to get the work done – it’s about how your teamworks together.
Agile essentials
Tap into that agile spirit by paring it down to its essential characteristics. This will helps teams come to a shared understanding and adapt to new information, as opposed to executing a pre-ordained plan. The four main hallmarks of these efficient and productive teams are:
– Customer involvement in the process: Teams develop an evolving prototype that allows them to enter into dialog early in the process, where they can receive repeated and evolving feedback from customers.
– Self-managed teams: Free from micromanagement via progress indicators and frequent prototype demos, these teams determine frot themselves how they’ll get the work done and deliver visible indicators of progress.
– Build and iterate: Teams divide large efforts into smaller tasks, and then perform cycles of building and testing to learn quickly from prototypes. The goal of each cycle is to create a deliverable, then get customer feedback.
– Reflect and learn: Each team – and the organization at large – reflects on past projects and digests this information. Reflection enhances organizational learning and improves processes.
By applying these principles to business cycles with specific, predetermined deliverables and hard deadlines, agile organizations can turn a mandatory exercise into a business advantage.
Start with the end in mind: driving toward the MVP
In order to scale agile practices across the organization, senior managers need to lead the way. And it’s important that in the early stages they understand the constraints they’re working with. For example, many companies must comply with financial reporting regulations like the Sarbanes-Oxley act, or consumer privacy laws like the CCPA and the EU’s GDPR.
These business processes have dependencies, milestones, and operational rituals that are sacrosanct and must be acknowledged and adhered to. If you try to apply agile methods in ways that don’t make it easier to complete the work – fitting a square peg into a round hole – you may end up frustrating everyone involved and failing to meet requirements. Or worse, facing a hefty fine or legal proceedings.
These business processes have dependencies, milestones, and operational rituals that are sacrosanct and must be acknowledged and adhered to. If you try to apply agile methods in ways that don’t make it easier to complete the work – fitting a square peg into a round hole – you may end up frustrating everyone involved and failing to meet requirements. Or worse, facing a hefty fine or legal proceedings.
The key to applying agile principles to pre-defined processes is to first identify the MVP – the minimum viable product. This may be the final report you have to deliver or the new operating system you have to set up to meet an ongoing compliance requirement. Likely, there is a hard deadline for the deliverable, so you should include that in the MVP, too.
Next, examine this fixed business process to identify each subprocess – the smaller components that drive the larger, inflexible requirements. Then, decompose these subprocesses, much like you would do with requirements and user stories. This will reveal how to analyze the work and design a path forward.
Release planning and the MVP
Another way to bridge agile principles with inflexible requirements is through release planning. Most agile development teams don’t think of a schedule, date, or dependency as part of their MVP.
But when there are regulatory requirements involved, the team could make the key due dates part of the MVP. The date becomes a requirement to be met, like any other non-negotiable element, and the organization can use a team-based approach to meet it. Include in the release plan the process owners – or the “customer” – that need to approve the final product. Insert milestone-driven dependencies into the release plan.
Take action, focus on outcomes
Senior leaders charged with assembling a cross-functional team are likely to encounter team members who are unconvinced that agile practices apply to this type of work. Here are some actions those leaders can take to convince skeptics, and bring agile to heavily constrained aspects of products and processes, such as regulatory or statutory requirements.
Examine the value of the compliance effort to the business. Likely, you’re performing this compliance review or audit because you don’t have a choice. It’s helpful to clarify to everyone involved what’s at stake and why this effort is a priority, just as you would when beginning a product development effort. Highlight what’s at stake, how the business will benefit from this effort, and what happens if you fail.
Name the customers and stakeholders. The “customer” is the entity that accepts the work and determines whether you’re in compliance. It may be an internal department, like legal or marketing, or it may be an external auditor or a governing body. Your stakeholders may be other people in your organization, such as other department leaders or board members.
Identify any dependencies or deadlines. For this type of work, this step is critical. There is likely a firm deadline by which you must deliver your MVP to your customer. If you need to get a report from one department in order to compile a report for the customer, document this dependency. Also, account for any “edge cases,” such as known gaps in your data or peculiarities in your business that may need to be addressed.
Break the work into sprints that lead to on-time delivery of the MVP. A work-back plan isn’t very agile, but in this case, there’s probably no way to avoid this. Plan where you want to be at the end of each sprint: “By sprint two, we want to see how this aspect of the regulation is covered; by sprint three we want to see how we might meet this part of the regulation.”
Assemble the delivery team. Determine who needs to be involved in the work, based on skill set and availability. Also, consider what they won’t be working on while their attention is on this effort, and make sure another priority workstream won’t suffer in their absence. Name the team leads and each person’s roles and responsibilities.
Plan resources for each piece of the work. Identify what’s required in terms of budget, tools, workspace, and support staff. Like with the delivery team, make sure you’re clear on any other priorities that may be competing with these resources so you can make sure their time, attention, and funding are protected.
Account for organizational or cultural considerations that may impact delivery. Perhaps your organization has been through this compliance process before. Take note of any other organizational initiatives that didn’t exist before that may impact this effort. And if there has been a significant change to how people are working, such as they’re suddenly remote or there are people in new roles, take into account the time and tools they might need.
Know how you’ll track work, make it visible, and get fast feedback. This is the part of the work where agile practices really shine. Teams that use the best product delivery tools can make their work and their progress visible to stakeholders and take in any feedback or new information along the way. With these practices and tools in place, the work can move along with steady velocity, and everyone can be assured they will deliver an MVP that will be accepted by the customer.
Plan for how you’ll capture lessons learned and improve the process. There’s a saying: Don’t wait until the horse is dead to perform the post-mortem and find out what killed it. By then, it’s too late to save the horse! Likely, this work will come around again, and the business will want to get better and faster at completing it. Use a collaboration tool that allows each team member to document lessons and suggestions for improving the compliance process in the future.
Extend agility into high-stakes processes for maximum benefit
If we see a regulatory requirement as a large, inflexible beast, it can seem as if agile is not the right toolbox to bring to the job site. But when we take the approach of delivering an MVP and divide the work into a set of sub-processes you can use an agile, team-based approach based on iterative loops and periodic reflection, building on incremental – yet significant – improvements.
Managing inflexible requirements with fixed schedules, imposed from parties outside of the company, seems like a difficult environment for agile. But that’s exactly why it’s important to do. If the least likely areas of your company can be made agile, then the promise of agile at scale is within sight.
When President John F. Kennedy launched what would become the Apollo Project, he said that the U.S. would achieve its aspirations in the space race “not because they are easy, but because they are hard.” Agile at scale takes hold when you apply it not in the places where it’s easy to do, but where it’s hard to do. If your organization can do this, you’ll have the agility and resilience to take on any challenge that comes your way.
Transform faster. Drive better results. Jira Align takes you beyond real-time visibility of work and towards true enterprise evolution and transformation.