Manifesto for Agile Software Development

I was reading a great code-rant on Agile Software Development, the sensationally titled Why Agile has failed! and stumbled upon the Agile Software Development manifesto. What is Agile? Well, the above article demonstrates what it is not. It’s not this:

Curiously, I’ve never read the Agile Software Development manifesto before, but here it is. It’s 4 lines:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Are you doing this in your organisation? It’s certainly something we are striving to do! Sometimes successfully, sometimes unsuccessfully. Hopefully,we are getting better as time goes on.

How do we ‘do Agile’?

A few months ago we wrote an article on How we Handle Support & the Roadmap. In it we said:

Sometimes a feature has to be backed out at the last minute because quality is not high enough … We take care that every release is of high quality. We don’t want to ruin our hard-won reputation as the Best WPF Chart by releasing shoddy software … So, great care is taken that each feature works, is tested and documented, either by KB article, release note or example.

We prefer to document by example as its live, you can see it, play with it, we can test-it each release, you can browse the source-code and it never gets out of date (you’ll never get a compilation error from out of date docs).

When I re-read this, its closer to the Agile Software Development Manifesto (and further from Dilbert-Agile) than I first realised!

How we implement … 

Individuals and Interactions

We promote direct interaction between customer and developers. In our teams we strive to communicate with each other, and share knowledge rapidly to best solve a problem.

Working Software over Comprehensive Documentation

We prefer to document by example, and iterate fast on features and improvements. By delivering fixes to you via a NuGet Nightly Build you can sometimes get the features and bug fixes you need within 24-hours! Guess what though, we don’t have a 250 page PDF user-manual, although we do have a living, growing KnowledgeBase.

Customer Collaboration

Did you know some of our customers submit fixes or improvements to the source which we include in the build? We work closely with customers to ensure they get what they want and we collaborate directly with you to create SciChart.

Responding to Change

Sometimes a feature has to be backed out, sometimes a deadline has to move. Sometimes it just can’t be done. Sometimes, it all needs to be dropped, and something else needs to be done instead! We are not rigid. You have to have a plan, sure, but you have to be ready to tear it up too.

So, hopefully, we are more agile than we first thought 🙂 Sure, we have a few tools and processes too. We use JetBrains YouTrack, TeamCity and ProGet to automate continuous delivery, we have tech-support Dave, what else do you need to create a successful software business?!