White Papers
Taking Good to Great: 3-Factor Risk Assessment
There has been increasing concern about information security around the world over the last decade. The information assets of many companies have been shown to be vulnerable to attack and breaches have occurred. We have been asked many times to help give our customers and other stakeholders assurance that their information assets and intellectual property are well protected...
Download the full article to learn how to use 3 Factor Risk Analysis to take your risk process from good to great.
"7 Dirty Words" to Avoid in Agile/Scrum
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.
Download the full article for an examination of these “7 Dirty Words.”
Agile Requirements: Built to Change
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.
No Rule is Universal
I was recently reminded of something that I think we are all generally aware of:
No Rule is Universal
Ironically, maybe ONE rule actually IS universal, and it’s that none are!! No rule is Universal because all rules need to be applied against a specific situation and the context of that situation may alter or invalidate how the rule applies. All rules need that context in order to be applied properly and we need to understand the context in which we will apply a rule before attempting to apply it.
Read the full article for more information.
(PHOTO BY EMILIO KÜFFER (HTTPS://CREATIVECOMMONS.ORG/LICENSES/BY/2.0/))
Agile Offshoring: Personal Interaction Pays Off
In Agile software development people are not interchangeable cogs where anyone can be swapped in and out on a regular basis; people are your greatest asset.
It’s preferable to have a collocated team of highly motivated individuals who are working together on a daily basis to create something great. But sometimes business needs dictate that the team cannot be fully collocated and you need to work with offshore resources. While not ideal, keep in mind that you can make offshoring effective, but you need to work at it.
Read the full article for more information.
Agile Offshoring: Not Just a Handoff
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.
If It Doesn't Run - It Ain't Agile
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.
Agile or FrAgile: Agile Development Needs Integrated Test
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.
The Agile Manifesto - "Over" Does Not Mean "Ignore"
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."
Subscribe to our Newsletter
Interested in hearing more from DESARA?Subscribe to our newsletter to get notified on upcoming webinars, events, training opportunities and more!
