5 Common Misconceptions About Agile Development

After many years of seeing a large number of IT projects fail, a group of experienced and recognized software development "gurus” met “in the need for an alternative to a documentation driven, heavyweight software development processes”. Based on their past experiences, they agreed on a set of basic guidelines they called the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

And as if they had anticipated that this simplicity might lead to misunderstandings, they added that they indeed see value in the items on the right but even more value in the items on the left.

So while they just expressed a preference for one item over the other, it occasionally is interpreted as an either-or option, making both items mutually exclusive alternatives. “Over” is replaced by “Instead of”.

What, for example, is meant as, “I would rather be flexible to be able to incorporate changes than having to stick to a rigid plan” mistakenly becomes. “I want to respond to change thus I do not need a plan,” which brings us to one of the most common misconceptions about Agile development:

Misconception #1: Agile does not need any kind of planning

In order to understand how planning works in Agile, let’s first look at how planning is done in a traditional Waterfall environment.

Detailed plans are created upfront to measure progress, detect deviations, and predict outcomes. Despite meticulous planning, though, a large number of software development projects result in costly delays, which leads to the conclusion that this predictability seems to be a mere perception.

Furthermore, predictions do not necessarily become more accurate as there is no mechanism in a traditional environment allowing to integrate learnings into the plan.

In an Agile environment, on the other hand, there is a common understanding that software development is a complex process that has a level of uncertainty.

Therefore, planning is done to a small degree prior to a project and mainly carried out in an incremental fashion throughout the development process.

How is that achieved? Due to rapid iterations and feature-driven development, new data such as customer feedback quickly becomes available, supporting both short- and long-term planning. Instead of making assumptions, teams have access to real data, allowing them to make much more accurate forecasts about what they are going to deliver.

By constantly planning, estimating, prioritizing, and delivering predictions significantly improve.

Misconception #2: Agile does not require documentation

Both stakeholders who have spent hours writing lengthy requirement documents and developers who have meticulously followed them know the frustration of discovering misunderstandings in requirements during development or after a feature is released.

This is neither the fault of the stakeholder nor of the development team. Written words are subject to interpretation. Take the example of an apple: While both you and I know what that is, you might have the sweet red type in mind while I prefer the slightly sour green one.

That is why Agile fosters conversation between teams in order to achieve a common understanding among customer, stakeholders, product owner, and every single developer, thus making sure everyone is on the same page with regard to what is to be achieved.

This does not mean, though, that documentation is not needed at all in an Agile project: User stories are added to the backlog, wireframes are drafted, user flow charts are created, grooming meetings are conducted with the client and the findings are documented in whichever form is adequate for the project. Business and technical details are added to Jira tickets before and during a sprint. Just as with planning, Agile documentation happens step by step and to the extent needed.

In case there is a disagreement on the necessity of such documents (usually between the product owner and the team), Mike Cohn suggests two guidelines:

• In case the development team finds it useful to document during the development process, e.g. source code, design guidelines or anything that they deem beneficial for software maintenance, they would naturally do so.
• In case the product owner or stakeholder requires a piece of documentation, for example, a document describing database tables and fields that the team would not produce anyway, it is added as a task to the backlog.

Misconception #3: Agile does not work for projects with a deadline

“When will everything be finished?” is most probably one of the first and most pressing questions from management and business owners even before a project has started. Whether that date is a rough estimate, a pure “wish date” or an externally imposed one, there will always be expectations in form of a projected release date.

To understand how deadline and Agile go together, let’s look first at how deadlines are handled in a traditional non-Agile setting.

In a traditional approach where all requirements are set out at the very beginning of the project, success is measured against how many of these requirements are implemented. Towards the end of the project, once the deadline approaches, such projects tend to depend on a lot of overtime. While this might increase productivity in the very short term, the productivity loss once the project is finished has a significant cost.

Agile projects naturally also start by looking at a huge wishlist of features. By looking at a broad range of options, we are trying to make sure that we do not forget the essential ones. Then, however, those have to be prioritized by customer value and it is necessary to decide which ones are really needed.

Agile approaches acknowledge that features that might be viewed as essential prior to a project are likely to change based on feedback gathered from early and frequent releases of those features. Short iterations and having working software assure we have a tested, working product that is likely to contain features that the customer wants once the deadline arrives.

There might be projects, though, where it is not an option to cut scope and have just the major, important features up and running. One of the benefits of an iterative approach is that delays can be noticed early in the development process. Because of this, there will most probably still be enough time to adjust resources. If these warning signs are reacted to early, the axiom that more developers slow down the process rather than accelerating it does not apply.

Misconception #4: Agile development is efficient

Let’s review first what some terms actually mean so we are all on the same page. According to Oxford Living Dictionaries the definitions are as follows:

“effective. Successful in producing a desired or intended result.

efficient. (of a system or machine) Achieving maximum productivity with minimum wasted effort or expense. (of a person) Working in a well-organized and competent way.”

So efficiency means how well we are using our time while effectiveness is all about achieving a specific purpose.

To put all this into perspective, let’s look at the two concepts of building the right thing, that is, developing a product that customers need and want to buy, versus building the thing right, which means building it in an efficient way, not wasting time and resources.

Inefficient and ineffective: Doing the wrong things badly is—needless to say–not desirable.

Efficient but ineffective:Doing the wrong things but doing them really well. We are efficient but we do things that nobody wants.

Inefficient but effective: We are building the right things but inefficiently. Definitely a better position than the previous because we are earning money which gives us time to become more efficient.

Efficient and effective: Definitely the spot where we want to be: doing the right things and doing them right. That’s where we build products that customers love.

And the morale of the story is: Without effectiveness, efficiency is useless.

So is there no place for efficiency in Agile then? There is, but rather with respect to the rituals and processes established within an Agile environment such as more efficient standups, retrospectives, planning, and deployment processes.

Misconception #5: Agile is always better than Waterfall

As we have seen previously, Agile will not be your first choice if you are an efficiency junkie. But which one is really better? Are there projects in which Waterfall is more suitable?

Agile and Waterfall are such opposites that it’s hard to say which one is better. It really depends on the project, the level of clarity around requirements, and how flexible you can be.

If you have a clear picture of what the final product should be (e.g., if you have done it many times before), or you have fixed requirements that will not change, some argue that Waterfall is a better choice than Agile. If you have a high level of confidence, Waterfall is a straightforward, efficient process. The issues with Waterfall come when you have to accommodate changes.

Agile should be your first choiceI when it is unclear what the final product will look like, when changes are likely to occur and when the project at hand has a significant level of complexity. Waterfall does not allow going back to a completed phase and making changes without a significant amount of rework and increased cost, whereas Agile methods allow handling new issues, and adjusting requirements, and can help reduce the cost of change and uncertainty.

References

The Roots of Agile Project Management. Rick Fredman. http://www.techrepublic.com/blog/tech-decision-maker/the-roots-of-agile-project-management/

The Agile Manifesto. K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J.Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland, D. Thomas. http://agilemanifesto.org

5 Myth of Agile Development. Robert Holler. VersionOne. https://www.versionone.com/pdf/AgileMyths_BetterSoftware.pdf

The Agile Misconceptions. Haniel Croitoru. https://techcommunity.microsoft.com/t5/Office-365/The-Agile-Misconceptions/td-p/33777

Handling Requests for Unnecessary Artefacts. Mike Cohn. Mountain Goat Software. https://www.mountaingoatsoftware.com/blog/handling-requests-for-unnecessary-artifacts

Making the date. Ron Jeffries. http://ronjeffries.com/xprog/articles/jatmakingthedate/

Deadlines in Agile. Stephan Kristiansen. https://www.frontrowagile.com/blog/posts/80-deadlines-in-agile

Efficient. Oxford Living Dictionaries. https://en.oxforddictionaries.com/definition/efficient

Effiective. Oxford Living Dictionaries. https://en.oxforddictionaries.com/definition/effective

Scrum is a Very Inefficient Framework. Victor Grgic. https://leanarch.eu/2013/01/31/scrum-is-a-very-inefficient-framework/

Agile Efficiency, an Oxymoron (Video). Gary Straughan. Development that Pays. https://www.youtube.com/watch?v=8-xrByDBl0U

Deciding what Kind of Projects are Most Suited for Agile. Mike Cohn. Mountain Goat Software.https://www.mountaingoatsoftware.com/blog/deciding-what-kind-of-projects-are-most-suited-for-agile

Agile vs. Waterfall: Waterfall wins! Gary Straughan. Development that Pays.  https://www.youtube.com/watch?v=8Nrw8pho6cY