Agile Transformation
Handling bugs with Scrum 
Martin van Vliet 28 Oct, 2007
Share 
At some point, you get a nose for things that don’t feel right. Things that sound reasonable when explained, yet you get that gnawing feeling it sort of goes against nature. Working with Scrum and compliance to ISO is one of those things. Here are 5 ways to merge a rigid security standard, without violating Scrum values like focus, openness or its pillars, transparency, adaption and trust.
Why? why? why?
[pullquote]“I am not mad; too well, too well I feel” – Shakespeare, The Life and Death of King John Act 3, Scene 4[/pullquote]
Well, as with anything: because the market demands it. Rightly or not, some customers feel reassured by the knowledge that their supplier has a process in place to deal with their sensitive date. Taking good care of that data is not a strange thing to ask. It’s just that in some organization the implementation has effectively strangled the agile mindset, and in others, it didn’t.
So if the market demands you take this medicine, what is the spoon of sugar?
What is ISO 27001?
It’s an international standard for information security, but rather than copying Wikipedia, let’s zoom in on the 5 aspects it covers and see if we can make it work with Scrum:
- Context of the organization
- Leadership
- Planning
- Support
- Operation
- Performance evaluation
- Improvement
1.) Context of the organization
An often-overlooked intent of the standard is to allow companies to apply certification on a subset of the process. Rather that copying the reference template, it would make sense to first figure out which clients’ request certification and for which products and or services.
You may find that the scope is a lot smaller than you would expect. But when you have identified this, you will probably also find the Scrum team in your organization that is responsible for it. It is very likely that it does not touch everyone in your organization!
Since the team is self-organizing and market aware, this is not the first time they hear about the importance of information management and you will find evidence of it in their Definition of Done and in their way of working.
Now the standard requires this to be written down, but what they really mean is that it should be auditable. So, if you run a set of penetration tests every release, keeping the log around is sensible, but you already did that right?
From a lean perspective, it’s waste: we are storing stuff for auditing purposes, not because it adds value. So minimize it as much as you can. In one company we had automated the entire process and you could trace any change starting in Jira until the running Application and it required near zero interaction for developers.
2.) Leadership
This is probably the most hazardous clause in the standard. It requires the management to:
- Commit to upholding security (that shouldn’t be a problem)
- Establish a policy (but doesn’t specify the format / media)
- Assign responsibility and authority to relevant people
This one is the trickiest because in Scrum the team should be self-organizing and now have this information manager running around with authority and responsibility. At one occurrence this led to what the team called ISO-Gestapo.
But the standard doesn’t say you should assign it to a person… it just wants to make sure that we adhere to the standard and report if we don’t. Inspect and adapt is the core of what we do. Transparency, well…
The one thing that should be considered is how to inspect and a share the results if your context is larger than a single team. It is nothing that a Scum-of-scrum ritual won’t fix, but you may need to document it a bit for auditing purposes. Be creative:
https://www.youtube.com/watch?v=NcB0ZKWAPA0
3.) Planning
Planning is not about creating the perfect plan, but about the process. So figure out what to do in a consistent way. In many ways, this is similar to what a Product Owner does to figure out what is value.
- Devise some form of method to assess security risk levels
- Say NO sometimes
Whoops, what did I just write? Well since good Product Ownership is defined by saying no to things that do not deliver value, there must be an equal threshold when assessing risks. If we do not have a threshold, the list will just grow and grow and eat all our resources.
Just another risk matrix
Try something like this. If your matrix does not have any level that you find acceptable, you will eventually drown.
It also mentions that you should develop plans to meet your security objectives. We have an agile recipe for that too. It’s called the user story, well; let’s call it the security story:
As a <persona that suffers from the risk> will suffer, when <security event> occurs. Which would lead to <impact for the persona>.
Example:
As Internet banking user, I would suffer when an external party would get access to my account. Which could lead to loss of capital or even debt.
Plans to resolve this risk could involve two-factor authentication.
As an Internet banking user, I cannot access my account without a two-factor authentication so that access is based on something I know (password) and something I have (e.g. a card or a phone.)
Of course, this is oversimplified, but it easy to see that managing a backlog of these is a suitable implementation of creating plans and adheres to the adaptation pillar of Scrum.
4.) Support and operation
Basically, it says: “do or do not, there is no try.” Don’t write a plan and put it in a drawer, don’t create a structure and then circumvent it, don’t say you will do penetration tests and then skip them because it is too hard.
“Do what you say, say what you do”. By incorporating the practices in the Scrum process, they become part of the natural cycle. This means people will get trained on it, just as on any other practice, the team deems necessary.
As said before, you may need to create a paper trail in order to be auditable, but keep is as simple as possible and automate the hell out of it.
5.) Performance evaluation
The standard asks for impartial auditing and an internal audit procedure. The sentence in itself is enough to raise several red flags for those with an agile mindset, and as an agile coach you can see either a control gate that will slow us down or a “Gestapo” that will interrupt our process.
It’s not that we mind periodic evaluation of performance, in fact, we welcome it. The inspect and adapt loop is at the very core of what we do. Think of the daily scrum, the sprint review, the sprint respective, automated testing, pair programming etc. But most of these rituals are team based and exist within the context of trust. A team is a safe place; the transparency comes from the fact that we are safe to make mistakes and we work on the same goal. External auditing doesn’t feel like a match, or does it?
I recall one project where 3 teams were working on a new platform, but discovered after some sprints that they had used different patterns to solve similar problems. The teams concurred that this would make maintenance more complex. Rather than appoint a central architect that would decide what pattern to use and direct the teams, they started peer reviewing each other. It did not only solve the issue on architecture patterns, but also things like integration tests, deployment scripts etc. But most of all: it expanded the circle of trust.
Rather than an internal auditor, go for a security chapter (or guild if you are bigger, but you may need to revisit the scoping chapter if you are that big.) Ashley-Christian has a nice explanation.
Improvement Requirements
Duh, we are doing Scrum. This is what we do. By integrating ISO in your Scrum process lots of aspects are handled automatically and in a collaborative way, much better than copy/pasting a control structure that strangles your agility.
Conclusion
[pullquote]"I think if you try hard enough and make the best of a situation, the situation won’t get the best of you." – MacGyver (Birth Day)[/pullquote]
You don’t need to accept a standard template of ISO and strangle your agility. There is enough room in the specification to make it work and strengthen Scrum rather than weakening it. Disclaimer, we haven’t certified this yet. But with similar experiences in ISO 9001 and CMMI it should work just fine.
Want to learn more about agility, martial arts and product management? Go order the book from bol.com if you are in the Netherlands or Belgium or sign up to get the international edition.
