- If you want to know how scrum/XP/kanban works, this post is not for you.
- if you want to know what the agile manifesto is, this is not for you
- If you want to know how CMMI and agile can live together, this is not for you
- If you want to read what good and bad agile are, this is not for you
if you want a high level understanding what agile is about in less than 500 words, keep reading. I'll do my best explaining it concisely.
I've been lost in the amount of information about agile methods before, so to help you avoid that, you just need to know this.
Agile is not a process; Agile is a mindset.
(And may I also add, agile is a buzzword so people can remember it more easily.)
If I had to summarize agile software development in one sentence, it would be this.
Try to ship useful, non-buggy software quickly using the simplest process that is still feasible.
By useful, I mean it gives what the user needs. By feasible, I mean meets the constraints imposed by outside entities, such as complying to the law.
That's pretty much it. Before I understood this, I got lost in the concrete techniques and buzzwords that people use to improve productivity.
For example, test driven development isn't agile. It's just a technique that has proven to improve productivity, and thus falls into the agile mindset.
On the other hand, mission critical projects that have hundreds of documents and processes can also be agile as long as those hundreds of documents have the least overhead in order to complete the project.
So how do I "ship useful, non-buggy software quickly using the simplest process that is still feasible"
You can reach this goal just by focusing on one thing: get early feedback on all activities.
Here are examples.
|have customer onsite||know which feature to focus on|
|automated test||know if new code breaks expected behavior|
|continuous integration||know if new code breaks the system build|
|daily meetings||know if your team member needs help|
|pair programming||know if you wrote buggy code or not|
When will agile not work?
The main thing people fail to notice is that they should choose a technique that works for their project and not just use the techniques blindly. Those are the people who hate agile and think it's broken.
Do you want to try agile?
My workplace just started using agile for almost a year now. As much as I dislike buzzwords and rather just say that we've followed some good practices, some agile techniques work for us and keep us focused.
The only advice I can give you is, if you want to be more productive and don't really care if you're agile or not, just try out 1-3 popular agile techniques, such as automated testing or daily standup meetings, and see if they work or not. If they don't, just move on.
If they don't work, you're probably already productive anyway. Plus, by moving on and not blindly following processes, you have the agile mindset already.