Overview
Lets talk about Agile software development. We'll cover a few misconceptions, and some
good old-fashioned common sense.
Don't get hung up on the buzzwords. The IT industry is relentless in its use of ridiculous terminology.
Just know that a Sprint means doing a piece of work in a specific time frame.
And what is a Scrum?
It's when two sets of eight large, sweaty people push each other around in the middle of a muddy field. Don't let anyone tell you otherwise.
The Agile Manifesto
Here it is. Nothing too fancy. Just some basic principles to follow to improve
software development.
Most of it is basic common sense.
Is it really sensible to spend six months producing an enormous requirements
document that may have been right at the time, may have involved the appropriate people, and may have captured the correct business requirements?
(That's rhetorical of course.)
I once worked in a large project team with a Business Analyst who was extremely proud of the fact that he'd been a driving force in creating hundreds of pages of requirement specifications in more than half a dozen projects, and not one of them had ever gone "live". He had laid waste to entire forests to produce documents that nobody ever read.
However...
Documentation
Agile is not an excuse for not doing documentation.
Let's be clear on that point because it's important.
Despite the fact that we do not want pointlessly huge requirements documents, we do need some "paperwork". We know that techy nerds, as a species, are averse to typing actual words instead of code so we want a central, easy to maintain, collaborative repository (let's just call it a wiki for simplicity) where the entire project team can be involved. We want useful, well-organised pages that complement our development effort.
Confluence from Atlassian is a superb tool to achieve this. It will take the most die-hard non-documenter and help them to write important things down.
Do not create spreadsheets of tasks or requirements and email them to the team with increasingly long titles like Stufftodo.v1.2.4 release 7 (final).xls.
No. No. No.
Do produce pages in your wiki with bulleted lists that constitute a minimalist plan. Agree these plans with your team. Encourage collaboration. Update these plans as you go. We all like to know where we are in the grand context of a project.
Business Users are part of the Project Team
Involve the business people or you will fail.
You. Will. Fail.
You don't need a Business Analyst to write a requirements document - you need the business person
who knows exactly how the process works to tell you specifically whether your software is meeting their needs.
We "Say Agile" but we don't "Do Agile"
Being agile does not mean taking a single piece of work and breaking it up into a dozen fortnightly Sprints until it is completely finished. Sure you're having Scrums, making Story post-it notes and having Daily Stand-ups. But are you being agile?
Unless you are creating shippable code at the end of each Sprint, and the Business Users in the team are in agreement that you are on the right track, then you're doing it wrong.
You are looking for an iterative process that is creating usable software roughly every two weeks. No, it is not the finished product, but it should be possible to see that the finished product is an achievable goal and that you are on the right path to completion. This article, and particularly the two pictures at the beginning, explain the concept of how to "Do Agile" properly.
Customise
Use the methodology in the way that best fits your organisation. Adapt the processes to match the requirements of your business and do not blindly and strictly try to follow a methodology that doesn't fit with your needs, your people, or your business.
The people in the project team are your key to success - if they can't self-organise, then don't force the issue - find a way to help them get organised even if this is in a more traditional way.
Stay on target
Do not lose sight of the end goal.
Do not get distracted by the technology.
Always remember that your reason for working on this
project is to meet one or more needs of the business. The basic principles in the Agile Manifesto can help you to achieve this.
Go on, read it again - it will make even more common sense now.