Under agile, risk mitigation is a very key concept. Instead of talking about and being aware of risks, the first thing we try to do is to eliminate the risk.

When starting a project take a look at overall project risks and attack them so they are no longer a risk for your projects success. A possible example is: will WPF work as a technology for us? The first thing the team should do is create a quick prototype application to see if I can get WPF to work for our situation.

With every iteration take the time to look for risks at the outset. This might be something like: “We don’t know how to talk to system X”. For this case the first thing that should be written in the iteration is the integration with system X. If we can do it then everything is great. If not then we need to find a new approach and we still have time to do it.

If we tackle a risk and it takes 20 hours then we know we have 60 hours left in our iteration. Because all the other items we are going to do are easy (by comparison) and therefore should have fairly reasonable estimates, we can now see if we will hit our goal for the iteration or if we need to move some of the less important work items to the next story. Contrast this with doing all the easy items up front. We get almost all of our goals done for the iteration but then hit a spot that stumps us. So either our deadline gets missed or we code through the night to make the deadline, potentially writing buggy hack and slash code.

By tackling risks as our first priority we can eliminate the risk of having something bite us at the last minute. This helps with estimates, costing, and deliverables of our projects.

This is the most common defense I hear when I talk about implementing testing on a legacy project. To this I want to walk through a scenario for finding and fixing a bug in a common organization. I know that not every shop runs like this and that every bug is unique but just humor me for a minute.

If we say the average person here is making $85/hour this works out to just under $1084. And I was gracious with my estimates.

If a system gets 5 bugs a week: 5 X $1084 = 5420 / $85/hour = 63.77 hours = 8 days of effort

If more effort was putting into reducing bugs by adding testing then lots of money can be saved! Slowly the user becomes more productive, the helpdesk is less busy, the deployment team is doing less work, and the development team is less taxed under bugs. With all the savings across the organization you can hire more developers!

But how do you find time to do that when your team is overworked as it is under a slew of bugs and feature requests?

Simple. Don’t do it all at once. You don’t have to have 100% test coverage to improve quality. 1% over 0% is an improvement. If you have to tackle a bug, write a failing test to replicate the issue and then fix the issue. Ta-da regression test! You should never see that issue re-appear in your system (well unless no one runs the unit tests ever again). Maybe take 5-10 minutes while doing this to write a few other tests around the bug you just fixed too. Now the area you had an issue with has partial code coverage.

Just implement this stuff gradually and you will soon start to see the benefits.

So a Rational Unified Process Group started up here in Edmonton in October. I have no knowledge of RUP so I thought I should go check it out and Scott Ambler was the first presenter. Although by the end I did not have a real feel for what RUP entirely was I got loads of good information from Scott about the realities of software. It was also interesting to have about five people from Calgary join the presentation via a phone conference.

Software Development, Agile, and RUP

• In the U.S. the Department of Defense funds 60% of Computer Science projects. So the providers of waterfall still fund a lot of things and continue to perpetuate some bad methodologies.
• Documentation is the worst way to communicate. Documents age and die and you can not ask questions of a document.
• If you have a methodology to prevent scope creep you are failing to meet the clients needs. Why should we say that a client can not get a feature because it is not in a document from 2 years ago? Granted we need to charge for these changes but to just say no makes no sense.
• 69% of developers have adopted at least one agile technique. They may not know it is an agile technique though.
• 43% of companies are offshoring work.
• The success rate from a recent survey says that 63% of traditional projects succeed and 71.5% of agile projects succeed.
• RUP actually spawned a lot of agile techniques from it.
• “Defects are requirements”. If something needs to be done then it is REQUIRED to be done.

Modeling

• Modeling something is not a taboo in Agile. Most people do it but don’t tell our friends. Look down the iteration stack for potential problems and do up a model of something ahead of time. There is no harm in planning ahead as long as you allow that plan to change and evolve.
• models/diagrams/documents in agile should be just barely good enough. They should convey what they need to convey and that is it. Otherwise it is documentation for the sake of documentation.
• TDD is good at small details but modeling is good at the big picture. Know when to use each.
• 77% of agilists are doing up front modeling on software projects

Database Testing

• We need to be better about testing the database.
• Data is a corporate asset we should test it
• We can test things like constraints, triggers, defaults, stored procs. What if it gets dropped or changed? Testing should catch that and protect us while doing database refactoring.
• It is irresponsible not to test this.

Quotes From Scott

• “There are those that are agile and those that are offshored”
• “Why make decisions when you have the least amount of knowledge” (in reference to big design up front)
• agilist: “what if it is easy?”
  non-agilist: “I think it is hard, so it probably is.”
• “Oh well to heck with Calgary” (when our phone conference to Calgary got disconnected)
• “[For end users] testing to a spec is a waste of time”.
• “RUP done right is agile”
• “Friends don’t let friends use MS project”
• “If a client is smart enough to earn money they are smart enough to spend it”