The following blog post was written by Avanade alum Karel Deman.

Quite often, we come across some common agile misconceptions and myths. The success of an agile project is highly dependent on making sure we bust these myths. Total transparency, early conversation and agile coaching are key.

Myth: Agile projects are “out of control”. Successful, high-performing development teams are self-managing without a command and control structure in place. This might give the impression that they are free to do what they want, when they want to do it. Nothing could be further from the truth. Development team members are in constant communication with one another, and therefore are completely transparent. Scrum introduces cadences to the development routine to ensure that project progress is transparent through well-known ceremonies like Daily Scrums, Sprint Reviews and Sprint Retrospectives. There is nowhere to hide in agile projects.

Myth: Agile projects “don’t do architecture”. This is also interpreted as agile “doesn’t need up-front design.” One of the more common agile misconceptions is that development teams do all of their design work “on the fly.” Design and architecture decisions need to be completed at the last responsible moment, not the last possible moment. Some decisions will need to be made before you write one line of code, however– for example, around technology platform, frameworks, languages, patterns and practices. Architecture evolves, so does code, as you iterate your way through the software project. So, avoid big design up front. Throughout the sprints, architecture design decisions are continually made where it’s validated through functioning software. This is known as emergent or evolutionary architecture.

Myth: Beware of becoming complacent. So, here is the situation: a development team starts using Scrum, and they adopt Scrum practices and even the principles. But, after a while, progress is slow because the code base is a mess. What's happened? The team hasn’t paid enough attention to the internal quality of its software. Although the Scrum guide omits any technical practices, they are very important. It is often said that development teams are using the nouns (i.e., the rules of the game as described in the Scrum guide), but not doing the verbs (i.e., the engineering techniques). Typical complacent development teams believe in magic, where Scrum somehow will magically solve all their problems.

Many more myths exist and these are just the tip of the iceberg. Scrum is quite often given the blame for unsuccessful agile projects, where in fact, the likely causes are these common agile misconceptions. Constant education and early dialogue are the ‘secret sauce’ to agile success.

This blog post is the fifth in a series about Agile @ Avanade by author Karel Deman. Each part of the series will be published every other week.

• Part 1: Avanade’s Agile Approach to Faster and Better Software Development
• Part 2: Measuring the Success of Organizational Agility
• Part 3: The Right Projects with the Right Customers for the Right Reasons
• Part 4: The Importance of the Agile Coach
• Part 5: Common Scrum Dysfunctions and Agile Misconceptions