Protecting your organization’s information assets from exposure to risk is a wonderful goal, but do you try to protect from ALL RISK? Wisdom would indicate that it is not possible to protect from every conceivable risk. It is probably not even possible to protect your information assets from every reasonable risk. Businesses who adopt models such as ISO 27001 need to identify information security risks and use a systematic approach to addressing those with the highest priority.
Two-factor risk analysis is a common approach: measure first, the probability of a risk event resulting in a successful security breach, and second, the impact on the business if it did. This article advises the addition of a third factor to consider when prioritizing risks to address: consider the mitigating factors your business already has in place against each risk separately from the perceived probability that the risk will actually manifest and cause a problem. The addition of this third factor can guide a rational approach to risk treatment plans that align with security objectives and resources.
Download the full article to learn how to use 3 Factor Risk Analysis to take your risk process from good to great.
Even though many of the basic values and principles of software development made it through (mostly) intact in the world of Agile/Scrum development, there seem to be certain words and phrases that have been used for years with no negative connotation in my mind that seem to have become hot-button terms with some members of the Agile/Scrum community.
It is not that these terms are universally derided; people who have been around a bit longer and have a sense of software development history can generally do the translation in their head and get to the value of the underlying ideas without getting hung up on the surface terminology. But there are some in the community who have a more ‘black & white’ interpretation and go directly to the worst case interpretations associated with these words & phrases.
Download the full article for an examination of these “7 Dirty Words”
Requirements will always change for any non-trivial development effort. Since we know requirements will change it would seem to make sense to embrace that change and have a process that not only acknowledges the changes by embraces them.
Agile, which is all about building in a resilience to change. Responding to change is one of the core tenets of the Agile Manifesto. Being able to be responsive to change starts with the requirements. The requirements inform and shape our development all along the way.
Download the full article for a framework of notions to help codify thinking about requirements in an Agile context.
While having team co-location is the ideal for Agile software development, it is not always feasible for a variety of business reasons.
When you enter into a relationship to augment your development/test with offshore resources, it’s not just a hand-off. You are augmenting your in-house team and there are going to be inefficiencies introduced that you will need to work at to overcome and make work for you (as much as possible) instead of against you.
Download the full article for more on making your Agile development offshoring as effective as possible.
Integrating code and making sure it runs correctly can be tough. That is exactly why it should be done regularly (at least daily) throughout each iteration and not put it off until the end of the iteration. This is commonly called continuous integration.
The idea of continuous (or frequent) integration is not a new one, nor did it originate with Agile, but it is a cornerstone of Agile software development, and a goal many Agile development shops are not realizing.
Download the full article to learn the basic elements of continuous integration and why it minimizes the impact of the inevitable bugs that happen in any software development effort.
Sometimes companies doing Agile development are really just doing iterative code and fix. Not maliciously; they don’t seem to have a solid understanding of what doing Agile development really entails. The result is not realizing the full benefits of Agile development which often means low-quality frAgile code!
A common root cause of frAgile code is waterfalling test into the end of an Agile iteration. It’s not meant to be something where a lot of programming is done for the first 8 or 9 days of a two week iteration and then thrown over the wall to be tested in the last day or two.
Download the full article to learn why Integrating test with day-to-day programming tasks is essential for delivering (relatively) bug-free software on a regular/accelerated basis.
When people start looking into Agile, one of the first things they usually come upon is the Manifesto for Agile Software Development. People, particularly developers, fall in love with the simplicity and economy of thought packed into so few words. It resonates with people who have been working in software because it just feels right. But the economy of the Manifesto is a both blessing and a curse.
Download the full article to learn how disregarding the items on the right side of the Agile Manifesto statements has led to Agile being criticized by some as “iterative hacking”.