apm 11 1

All right, buckle up. We're about to jump into the thrilling world of Agile governance, audit and compliance. Yes. That's awesome. I know you can hardly contain your excitement, but seriously, governance, audit and compliance, they're critical components of agile project management. So the question becomes, how can these elements be integrated into our agile practices to support timely delivery of our valuable products and services? You know, in traditional project management, governance and compliance, it often followed a waterfall approach, a sort of big upfront design and then big bang release at the end. This method, however, it led to significant risks and delays. The legacy approach to compliance involved moving through waterfall phases with phase gates delivering documents to show progress. Most compliance related activities, like code reviews or security audits or regulatory checks were typically saved until the end of the project. This approach carries a significant risk. What if decisions made months ago were incorrect or no longer align with the rapidly changing market conditions? Unraveling these issues at the 11th hour can be extremely challenging and time consuming, potentially leading to missed market opportunities. Richard, we are screwed. And if critical defects or compliance related items are uncovered, they're often orders of magnitude more costly to fix. Agile is fundamentally about driving better outcomes by reducing risk, and you can't do that if you're saving important pieces of the development value stream until the end of the project. So the Agile solution, it isn't to abandon compliance, but to address it, to address it in smaller, more manageable chunks that align with the organization's needs. Our approach to compliance is to address it early and often. I like to say get compliant, stay compliant. This incremental approach gives us an early warning system for detecting compliance issues. Our goal is to be in a continuous state of compliance by incrementally building the solution and mitigating security and compliance concerns. And in small batches of work. Like most things we've talked about in this class, being agile isn't like a flip of a switch or something. So if you're doing compliance activities at the end of your project today, well, maybe your first step towards improvement is to just do them more frequently, like every quarter or maybe after every five sprints or something like that. Whatever it is, the trick is to just shorten the feedback loop. After that, maybe you just start to embed them into your sprint cycle. We want to make improvement steps and assure that we're doing things more frequently. And by doing so, we're making sure that there's no surprises at the end and that our solution is in a perpetual state of compliance. Likewise, we're producing the necessary lifecycle documentation. The central difference with our documentation approach is that the artifacts must be living documents. We need to have the ability to update and refine our specifications based on continuous feedback. By breaking the work into smaller chunks and addressing compliance early and often, you can identify and resolve issues much earlier in the process, ensuring your product remains market ready to now you might be wondering about traceability in this agile approach. This is especially important in regulated industries. With properly configured tools, you can maintain full traceability from portfolio epics down to build numbers and test cases, satisfying both internal and external auditors. I just want to point out that during your project kickoff, make sure you take time to configure the tools so that you can provide this traceability. But in general, once the tools are configured, pretty much all of them have out of the box reports that show linkages of various work items. That leads me to another element of governance visibility. Remember how I described the backlog? If it's in the backlog, we might do it. If it isn't in the backlog, there's no chance we're doing it in agile. Project stakeholders have full visibility into the work being done through accessible backlogs at every level of the project. This involvement, it ensures that the development team is working on the right things, because business representatives, well, they're part of the process every day, every step of the way. They're with us and they know what we're working on. A few years ago, I was working on a CRM solution for a global nonprofit. We've been working for months using traditional methods, and when it came time for the compliance review, we found a bunch of problems that required substantial rework. We decided to switch to an agile approach. Mid project. We broke down the remaining work into two week sprints, and then we integrated compliance checks at the end of every third sprint, aligning with key regulatory milestones. The results surprised everyone, even me. We caught issues earlier. We reduced rework and ultimately delivered a compliant product on schedule, allowing us to capture a significant market advantage. This experience showed me firsthand the power of integrating governance and compliance into the Agile process. Okay, your turn. How might you integrate compliance checks into your current sprint cycle? Think about the specific compliance requirements in your project, and how might they be broken down into smaller, more manageable chunks that provide continuous assurance? Effective governance, audit and compliance in agile environments requires a shift in our mindset from big, infrequent checks to smaller, more frequent integrations. By embracing this approach, you can ensure that your projects remain compliant and market ready while still delivering value quickly and efficiently, and all while maintaining a competitive edge in your industry.