How do we build Secure products in Scrum? In a world where the development team deliver value every Sprint, it is hard to see how to ensure products are secure and still delivered every Sprint.
People have tried different approaches over time, with varying degrees of success.
- Fix security issues as defects after the implementation
- Hardening Sprints (which is just a formal version of fixing security issues later)
- Special Teams – where the special team take care of the security work. Like all special teams in a Agile world, this team will likely become the bottleneck to frequent releases.
- Special Team members/experts become advisers or coaches to teams trying to improve the security of their feature work. This scales better than a special team, because we’re spreading the knowledge over more people.
- Automate – for classes of problems that come up repeatedly, use automated tools to spot the problems. This is not a panacea, it merely reduces the load so that the experts can focus on more important work.
- Definition of Done – Add the security requirements to Done. Now development team members are expected to check the specific requirement every time they declare an item as Done. Works well with automation, and experts become advisers.
- Acceptance Criteria – when team members meet to discuss other acceptance criteria (hint: BDD), they also review their Definition of Done, they’re reminded of security requirements. Based on this conversation, they write the acceptance criteria for that feature.
- Separate Product Backlog Items – if some security needs are large enough, they might become their own Product Backlog Item. Caveat: the risk here is that product can’t be released until key security features are implemented, contravening the Agile principle of “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
- Build into all Scrum events – ask questions that relate to security in Sprint Planning; Sprint Review; Sprint Retrospective and Daily Scrum.
Everything mentioned about security is also applicable to any highly-regulated environment where the team are required to meet a compliance goal.
Scrum Anti-Patterns: The Hardening Sprint
Scrum by Example – Stuck Waiting for Other Teams (Special Teams and their effect)
Scrum Development Team – Who’s In It?
- Continuous Compliance – Continuous Delivery with Compliance
- DevSecOps — How Security Can Be Assimilated Into Scrum
- DevSecOps Manifesto and What is DevSecOps?
- A Guide to Threat Modelling for Developers – Secure software design, little and often
- Managing Security Work in Scrum: Tensions and Challenges [PDF Warning]
- Product Security Risk Management in Agile Product Management [PDF Warning]
- SECURE SCRUM – INTEGRATING SECURITY WITH AGILE and the paper it was derived from: Secure Scrum: Development of Secure Software with Scrum [PDF Warning]
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.« Back to Glossary Index