“Responding to change over following a plan” is one of the tenets of the Agile Manifesto.
Risk management in Agile development often requires engineers to address changing threats throughout a sprint cycle. But being nimble should not come at the risk of derailing production. Addressing risks in Agile development — such as production delays, exceeding budget or stakeholder miscommunications — take a degree of preemptive planning.
When developing healthcare applications, common development risks take on added significance when the security of patient information and industry compliance are at stake. VP of Engineering Joey Leingang said he and his team have to plan for these contingencies at Eden Health, a provider of telehealth medical care solutions for employers.
Before each project, Leingang said developers familiarize themselves with all the potential risks and solutions presented in a technical design document. These risk dossiers are part of the company’s information security program — built collaboratively by internal and external compliance and technology experts — so engineers know what to expect.
Leingang said this awareness makes mid-cycle risk mitigation and response smoother. Production challenges are addressed directly via recurring Jira tickets and notifications from the incident response platform PagerDuty. Sprint retrospectives and process audits based on industry standards help the team maintain and improve their secure development processes.
What best practices do you follow to identify and plan for risks in software development?
Eden Health recently built a formal information security program that includes a Secure Development Lifecycle (SDL) process, among other things. The program was built in collaboration with healthcare technology and legal experts, as well as our internal legal and compliance team. We apply risk analysis to every aspect of the business, and software development is no different.
Every project has a technical design document with risks and mitigation steps included, so we start our work with an upfront picture of the magnitude, likelihood and causes of risk. When performing code review, our engineers — who are trained on secure development best practices — work together to ensure we ship with confidence.
A good Agile process allows failure to be an option so teams can learn from mistakes.”
What steps do you take to monitor for issues throughout the development process?
Starting with the most potentially impactful items, we maintain a risk register with specific rules about monitoring and validating. Using recurring tickets in Jira is helpful because these items need to be checked like clockwork.
But doing so throughout the development process is a different matter. We staff engineers exclusively to projects and designate one as the technical lead who authors the test-driven development. This staffing helps us strive for both accountability and autonomy, allowing the team to address the risks in whatever manner they deem the most appropriate. Because we are Agile and develop software iteratively with regular releases, we can test assumptions in the real world.
Are there any tools or technologies you use to make this process more efficient?
Every project team relies on our Sentry and Sumo Logic integrations for real-time telemetry out of our apps. They also notify us via PagerDuty of any anomalies. We run retrospective meetings at the end of every sprint to reflect on what worked well and where we can improve. By baking risk management and secure development into our core process, we make sure to address these issues as they occur sprint over sprint.
We periodically validate our process and risk-based outcomes through industry-standard audits. These audits aren’t entirely Agile in nature — an SOC 2 audit can take a year — but third-party application security scans, penetration testing and systems review are all part of a secure development process.
How does your team factor the pros and cons of an Agile methodology into your development process?
Working iteratively and releasing frequently is great because assumptions can be tested quickly. A good Agile process allows failure to be an option so teams can learn from mistakes and improve. It’s not perfect though, and where Agile can introduce a lot of challenges are areas where compliance means failure is not an option.
Our business, for example, is in healthcare and a lot of the risks we have to deal with on a daily basis are related to Protected Health Information (PHI). Any service we integrate with requires business associate agreements, which stipulate how PHI will be transmitted and secured. This scenario is fairly black and white, and there isn’t room for experimenting with real PHI. We actually designed our SDL based on PHI being an omnipresent challenge for our business. So thorough review of technical design documents is a routine part of our jobs.
