The technological footprint of companies has expanded exponentially. Almost every company today creates some software. However, most companies? business model, processes, and organizational framework have remained fundamentally unchanged. Analysts tell us we can gain more quality, faster time to market, and protect ourselves from digital disruption if we become more agile.
But how? What does this mean when you have regulations to adhere to and audits to pass? Let me dispel a few myths I hear as I talk to companies about agile in regulated environments.
I see companies keep their old, heavy, waterfall product life cycles while trying to allow teams to use agile methodologies underneath. The old processes slow the teams down. By forcing too much planning and estimation up front, you allow your competition to pull ahead of you and release before you. Those companies are getting real, customer feedback on their software ? and making improvements ? while you are still getting signatures on that product requirements document.
The teams that design and govern your product life cycle and software development life cycles need to fully understand agility. They need to understand all the benefits, why the best practices are considered best practices, as well as, the regulations you need to follow to create the right process for your company.
Agile is not just another process to follow. It requires us to change the way we work together day to day so we can create the best product more quickly and with better quality.
Shhhhh. Don?t tell the development teams, but there is actually more rigor in agile than in waterfall. There isn?t less governance; the command and control are passed to the teams. They are responsible for making sure they do what is needed to create the right product, at the right quality, within the window of opportunity, while also fulfilling the regulatory needs. You can still verify these things are done through lighter-weight reviews.
The teams need to track the work completed and provide daily status on where they are in their projects. You can tell within 2-3 iterations whether the project is on track and whether it will be completed as planned. For the first time, you should have real, consistent data, across all your projects that you can use to tell status, make tradeoff decisions, and run the business.
How much easier would it be to pass that audit if you could easily show full traceability within one tool? If they updated their progress against requirements daily?
Nothing could be farther from the truth. If your teams are following Scrum or Kanban, you should have no less than weekly status on how things are going. You have charts that tell you if all members of the team are engaged, if they are limiting their WiP appropriately, if the Product Owner is engaged ? things you never thought you would be able to see easily within a project in the old Gant Chart days.
Align your teams to a common definition of done, and you will definitively know how complete something is along the life of the feature. In my experience, I chose to define definitions of done for stories, iterations, and releases (final release criteria).
Ensure consistency across teams (data and workflow), and then use standard measures to verify what is complete. I had enough consistency across all development teams that I could pass the audits without the development teams needing to attend. This allows your teams to stay focused and productivity to increase.
