Agile MythBusters
#1 If we do TDD, we don’t need QA
TDD, also known as Test Driven Design, is more of a design activity and less of a testing activity. The word test in it can be very confusing for people. In fact, it is so confusing that some people think, we they do TDD they don’t need QAs. Folks like Dan North, identified this as a problem and coined a new term called BDD or Behavior Driven Development. This makes it clear that the focus is not testing, its expressing behavior. Another important fact to note is TDD is not just about unit level tests. People who do Acceptance Test Driven Development or Story Testing, write a failing Acceptance test and then write just enough code to make the test work. Irrespective of what level you write these “tests” [actually lot of people prefer calling it behavioral specifications or intentions], their primary purpose is to drive development, and is not to critique the product. QA who do exploratory testing and other forms of testing can add a lot of value to the development process.
#2 Agile is about Rapid Software Development
Agile is not about Rapid Software Development.
#3 Agile projects don’t have cost or budget estimated
I wish this was true. Life would have been peaceful. Like any other project [software or not], stakeholders want to know either of these
- How much would the project cost them? [Cost]
- When will the project be completed? [Time]
- What exactly will be delivered? [Scope]
In case of Agile we really like to keep these as levers or knobs that can be varied based on the need. We try and explain to the customer why trying to fix all these upfront, at the point when we have the least amount of info or knowledge is a really bad idea and recipe for failure. As far a estimation goes, there are different techniques available out there. Also we do not believe in a silver-bullet. Depending on your needs you will have to choose a technique.
#4 Agile projects don’t plan. It’s very chaotic and direction-less.
At the heart of Agile is the embracing change mentality. We strongly believe in adapting to change over following a plan. We do see value is plans. But planning for us is not a one time activity, its a continuous activity. We do not deliver to a plan, we plan to deliver. Guess what, no longer we have those big Microsoft project plans or Gantt charts that are followed as Bible. We plan, we adapt, we refine as we go. As more information is available uncertainty reduces. We strongly believe in embrace uncertainty. If you have not read Mary Poppendieck’s Lean Development and The Predictability Paradox paper, its a must read.
#5 Agile projects means No Contracts
The Agile Manifesto says “Customer collaboration over contract negotiation”. Which means, we still need contracts in place, but not at the cost of customer collaboration.
Traditionally contracts have been written purely to project the parties from taking advantage of each other. But unfortunately, over the last few decades, contracts have been used by companies as a shield. Each party tries to push as much risk on to the other party in contract. Which introduces a unique tension when it comes to writing contracts. Hence contracts have earned a really bad reputation over the last few decades.
IMHO, Contracts are not bad and contracts are supposed to help us to ensure we’ve come to a shared understanding of the terms upon which two parties will engage. Although one of the consequences of a contract is the ability to sue, which is known as enforcement, this is not its primary purpose. The primary purpose of a contract is to clarify the obligations of both parties. Most people honor their obligations when those obligations are clear. Having a clear understanding of which party is responsible for what furthers good client relations.
#6 On Agile projects We don’t write documents
Documents are another entity that most people in the software world hate. There are valid reasons behind this hatred. I have been in organization where we were document driven. Document was the only form of communication and document meant everything. We all know the issue with document. Agile emphasis on using richer forms of communication and collaboration. Also I have found a lot of places where people think writing the document finishes their job. Agile emphasizes on working software over comprehensive documentation. We tend to focus on lot of short lived documents/artifacts which does one job well. Also over the last few years, there are quite a few sophisticated tools that let you generate quality document from the code, rather than the other way round. We believe in executable specification over comprehensive word document.
http://www.agilemodeling.com/essays/agileDocumentation.htm is a good read.
#7 Agile teams cannot be distributed
Distributed development sucks in general. But Agile can help. Lots of organizations are finding it helpful to use Agile on distributed projects.
#8 Are there minimum processes to be followed to qualify to be Agile team
People usually tend to get into this argument. Trying to qualify a team as Agile or Waterfall. Basically this argument is a waste of time. We do not achieve anything by having this argument. Agile is certainly not about following a set of practices. Agile is a culture or value system. Hence its difficult to define minimum process/practices. The Agile manifesto can be a good guide if you want to ask this question to yourself. Also doing one or two practices does not make you Agile. Evaluating number of practices to Agile maturity levels is the funniest thing you can hear.
#9 User Stories are same as Use Cases
This is not true. There are quite a few differences between the two. Have a look at http://www.mountaingoatsoftware.com/article_view/27-advantages-of-user-stories-for-requirements
#10 In Agile, we start coding day one
This is not true. At least on the projects I have worked, we never starting coding day one. Again Agile is not about churning out more code. It’s about delivering business value. Agile and XP in particular is accused of “missing the forest for a tree” or “missing the big picture”. This is true to some extent, coz when we talk about XP, people talk about starting with iteration zero and then starting actual development. Sometimes we might need a couple of weeks to understand the existing business processes and understand the overall landscape. Usually I guest a 2 week period to do this, before the iteration zero. I certainly don’t recommend anything in months for this phase.
#11 My team uses a Agile project management tool, hence we are Agile
Using a tool does not make one Agile. Sometimes tools can help. And some times tools really get in the way. We refer to them as bloatware. Nor does using JUnit make you do TDD. Remember: “People and interaction OVER processes and tools”. Ironically, in my experience, Agile teams tend to use better tools than other teams. Also there is a lot more rigor and discipline when it comes to process on Agile teams.
