Monday, 21 March 2011 17:29
Written by AdventureTech
There are several common myths about Agile principles that might prevent your business from adopting them.
We're going to "debunk" these myths below and help make sure that you understand how Agile brings real and meaningful value to the bottom line of every business.
Myth 1: Agile means having no documentation.
Agile methods still produce documentation, but you only produce the documentation you need as you need it.
This provides the best combination of time, cost, and value that your documentation can bring you. You won’t have documents that take hours to produce and update simply because someone suspects they might be useful to someone at some point.
Myth 2: Agile means no up-front planning or decision-making.
Agile does not mean blindly jumping into a project with no planning. What it does mean is that planning is done as you need it, which is where planning adds the most value.
Having fully planned out every aspect of a project before you begin is a liability, not an asset. Many things will change between Day One of planning and completion of a project. All you’ve done is set yourself up to spend a lot of money for absolutely no reason at all.
However, planning absolutely must be done as you need it. The things that need to be planned and decided before a project starts ought to be, but nothing more and nothing less. The rest of the planning is done progressively as needed.
Myth 3: Agile prescribes a lot of practices and tools we may not want to implement.
Agile is a set of principles. Different people have come up with various practices and tools that they feel capture Agile principles, and some are so commonly used that they are virtually “Agile methodologies,” but there are no mandated practices or tools. Agile is not Scrum, XP, Kanban, or even such valuable practices as TDD. Those things may be very useful to a group trying to be Agile, but none of that is mandated by being Agile.
Myth 4: Agile is just a development fad.
When all the amazing developers are doing something and big names are trying to find ways to support it, and this has been going on for several years, it’s well past the fad stage.
It has become a common part of today’s development practices, not because it’s the Next Greatest Thing (NGT), but because it provides real and immense value when properly implemented. Writing Agile off because it is a fad is rather similar to writing off Object-Oriented Programming because it’s a fad.
Incidentally, I think that Internet thing will catch on one day as well.
Myth 5: Agile will not allow me to estimate.
Agile forces you to work with real data and metrics as opposed to wild guesses with no useful connection to reality. If by “estimate” you meant “make wild guesses with no useful connection to reality,” then this might not be a myth. I’d really like a video of the shareholders meeting where you announce, “We will not go Agile because we are solidly committed to giving you wild guesses with no useful connection to reality. Speaking of, let’s take a look at this year’s budget.”
I’m guessing by “estimate,” you mean, “give a useful approximation of when X amount of work might be done,” and in that case, Agile can not only provide that, but it bases the estimate on actual data that your actual developers produce.
What Agile will not allow you to do is make an estimate that can’t be justified with actual data, such as, “When do you think you can have a CRM built by?” You will be forced to break that question down into units that can be accurately estimated, and the estimates will be based on your developers’ actual past history, not their guesses.
Which would you rather make decisions on: actual historical data or your developers’ guesses?
Also, Agile development means you get feedback on the validity of that estimate early and often. If your project is behind, you can find that out on a day by day level as opposed to the month before release.
In summary, moving your organization in a more Agile direction does not do away with anything that provides actual business value (although it does do away with many things that don’t), and it provides that value when the value is most necessary, most current, and most accurate.
How would you like your organization to run?
Did you like this? Share it:
Post written by 
