Safe (Not Scaled Agile Framework) Agile Development

This was inspired by a brief Twitter interaction with @AsadSafariEN regarding this article:

There are several software-maker injuries mentioned in Joshua Kerievsky’s article:

  • Alteration Anxiety: apprehensive uneasiness associated with making changes
  • Antique Agony: mental anguish from working with old technology
  • Brain Hernia: straining your brain to understand code with high conceptual weight
  • Browser Bruise: pain caused by the blow of a browser bug
  • Bug Burn: feeling burned by a defect, particularly one that injured users
  • Fractured Flow: feeling interrupted causing an inability to focus
  • Fragility Frustration: dissatisfaction with that which is easily and perpetually broken
  • Merge Misery: suffering caused by difficult merges of code
  • Outage Ordeal: severe stress caused by a major failure or interruption
  • Release Rage: exhausting, manual release to production that robs one of family time, sleep, joy
  • Schedule Stress: tension associated with a deadline

One of the key benefits of the Agile approach to software development is that it tackles these kinds of safety problems and risks inherent in software development.

1. Alteration Anxiety

There are several agile techniques that tackle this concern. Test Driven Development is one of the best. As part of TDD, one would develop a set of tests that allow changes to be made in the confidence that nasty side-effects will be minimised. Also, pair programming is great for dealing with this. I use my internal feeling of fear for deciding when I should do pair programming. The more afraid I am, the more I want someone’s help! Pair Programming helps to keep one honest too. Pair Programmed code is generally less painful to change than the carelessly constructed brainchild of a single developer. Prevention is better than cure!

2. Antique Agony

Agile is not so great for dealing with this! Although, it is worth noting that incremental change can be a good way of managing a technical migration strategy. Rather than letting your technical solution fall behind the times, a series of small periodic upgrades can be interspersed with your standard User Stories. For example, recently I upgraded a system from Asp.Net MVC 3 to MVC 4. It’s a small upgrade that takes a little effort. Upgrading MVC 1 to 4 might be a bigger piece of work!

Again, prevention is better than cure. Don’t get behind in the technology stakes!

3. Brain Hernia

Again, here we turn to our old friend TDD. Sometimes code is hard to understand. The tests we build around the framework (unit, integration, acceptance etc) can help us understand the individual pieces of code as well as the context of that code. We should also remember that anyone on a team can ask for help and no-one can refuse to give it. Don’t forget that complex areas of code should be pair-programmed to reduce the heavy conceptual weight in the first place!

4. Browser Bruise

Our Definition Of Done is great for early detection of browser-related problems. My typical DoD includes browser testing on IE6 (!), 7, 8, 9, 10, FF, Safari, Chrome et al. This should prevent the cost of the browser bug being too high. Also, don’t forget to automate your GUI tests so that they can be included in your continuous integration infrastructure. This means that you will run these tests more often and catch problems earlier and reduce the size of the browser bruise!

5. Bug Burn

Our Agile quality goal is to release software without known bugs. Agile teams have a zero tolerance policy on bugs. Every time we find bug, we write a test to repeat the bug and then fix the bug. We include the test in our continuous integration infrastructure to ensure it doesn’t burn us again by sneaking back in!

Of course, the goal is to prevent bugs from occurring in the first place. We do this by employing Agile Testers and using TDD. Agile Testers are nosey and get involved early in the development process. They work alongside developers to help create a comprehensive set of tests to prevent defects from occurring the first place.

6. Fractured Flow

Agile methods such as Scrum seek to minimise interruptions by creating and committing to a limited feature set. The Team Leader (Scrum Master or whoever) protects the team from interruption during the construction of an increment of software. Agile teams also have simple, well-defined processes for altering the plan for product development. For example, a Product Manager is generally appointed who will be responsible for managing the feature priorities. This means that the production workflow of development, testing etc is not interrupted when new features are proposed for the software.

7. Fragility Frustration

Continuous integration is key here. Any fragile areas of software can be targeted and tested to ensure that they work. Inclusion in the standard continuous integration infrastructure means that these areas are continuously tested to ensure they remain operational.

Also, automated tests enable refactoring to take place. The fragile code are can be refactored into more stable piece of code. The automated tests allow one to be confident that the refactoring has not only stabilised the code, but also maintained the correct functionality.

8. Merge Misery

Agile encourages us to develop small user stories and deliver small increments of functionality. Agile teams are also reasonably small (less than 10 people). The most efficient Agile teams I have worked with NEVER branch. No branching means no merging. Staying within 15 minutes of releasable code means that branching and merging should be a thing of the past!

9. Outage Ordeal

Agile can’t help us much with infrastructure problems, however, a good Agile development process should include a realistic test system that closely mirrors the production system. Ideally we should be including load testing and failover testing as part of our normal Definition of Done or Iteration-level testing. This should minimise the occurrence of outage. However, you can never quite eliminate the problems associated with drilling through a network cable…

10. Release Rage

Agile teams stay very close to being able to deploy production code. Very early on in an Agile adoption, teams develop batch files, programs and other scripts in order to be able to automatically deploy to a production / test system with a single command line instruction. Those following continuous deployment strategies don’t even need to do this! Their CD system will automatically push code through to production environments. My current longest release process is 20 minutes and is semi-automated. With a little more work, we are going to get this down to about 5 minutes which is the time it takes to SFTP some files around.

11. Schedule Stress

Finally we get to deadlines! I am always reminded of Douglas Adams’ love of deadlines when this discussion comes up (Google it). Agile is great for managing deadlines. First of all, Agile teams deploy code to production continuously (generally I do two or three drops to production every day), so the “final” delivery is very little different from the first from a stress point of view.

Whilst the combination of Scope, Cost and Deadline can vary on an Agile project, most projects will tend to fix the Deadline and the Cost and vary the Scope. This means that if we are ahead of schedule we add more features in and if we are behind schedule we remove some features. If you aim to constrain all three of those factors, you can succeed, but it becomes incredibly unlikely!


If you are looking for a safe approach to software development, look no further than Agile!

Get in touch with our team to learn about range of Agile Services and Workshops to kick start your transformation.