I presented last week’s webinar “Create Agile confidence for better application security” (watch it here). The topic, how to embed security into Agile teams, took me back to my years of working in the Agile APM space. What struck me was some of the same questions that arose years ago still persist:
• How do you get people to embrace change?
• How can teams work with different functional mindsets, yet operate as a unified team?
• How do you build security into user stories?
• Where do you start?
I’ll answer the security question first, then follow-up with the others in future posts (stay informed on Twitter).
For years the pundits have been saying Agile has gone mainstream, yet some areas remain challenging – as they might with any methodology. That doesn’t signify a lack of adoption, simply that some of the issues teams and organizations face are perennial. At Rogue Wave, our development teams are Agile, and we’ve also designed and implemented a flavor of Agile for our marketing efforts (think Kanban or continuous flow), so we’re in the same boat as most of our customers.
“We all know that in the struggle between functionality and security, functionality always wins.”
One topic we didn’t get a chance to cover in depth last week was how to create user stories to include testing. So here it is. Testers can create their own user stories, but that carries the risk that as a separate task, security may get left behind during backlog grooming in favor of pure functionality. As Wendy Nather from 451 Research** told us, “If security is separate, it becomes optional.” And we all know that in the struggle between functionality and security, functionality always wins.
Telling your story
High performing Agile teams include testing and security requirements into their functional user stories. Remember, user stories take the form: “As a [type of role], I want to [desired ability], so I can [desired outcome].”
Consider authorization for an application, where a user story may look like:
“As an architect/developer, I want to ensure, and as a QA authority, I want to verify that users have access to the specific resources they require which they are authorized to use. “
So this includes both the functional aspects of the requirement (ensure access) and the security needs (appropriate authorization). Note the sub-tasks, or specific work effort, are not included in the user story to allow the team to determine how to best move forward. As the Agile Manifesto guides, people over processes.
Another key element is the definition of done. In this, the team determines the acceptance criteria and when they will accept the work as complete. A user story is not actionable until the team determines exactly what it will take to be complete. So in this example, the definition of done might include an authorization matrix, testing to ensure the authorization mechanism complies with the matrix, and both automated and manual tests.
Now the team is ready to add this to their backlog. Security is baked in from the onset, teams are clear on what is required, and testing is managed separately but as part of the sprint or iteration.
So that’s one question, but there are many more. So, on July 15 in our next installment of the Accelerate learning series, we will tackle all the questions from the first two webinars. Come armed with your own, and as a team, we can put some of these to rest.
**Follow Wendy Nather on Twitter, she’s engaging and informative.