10 Agile Myths & Misconceptions

Nomen est omen – the name determines its meaning. So, is ‘agile’ really about ‘agile’? If we talk about being adaptive – my answer would be yes. But does the use of agile methodologies also mean less discipline, less planning or less documentation? Definitely not. I think the biggest issue of agile is its misleading name. In agile, planning and documentation is just done differently than in traditional waterfall approaches. If you are an agile professional you of course know that. And you are for sure very annoyed about these (common) misconceptions. One other factor is the dramatically increasing popularity of agile in new domains, in which the term ‘agile’ is picked up and freely interpreted. Here is what I often see:

• Agile sells: Agile as a label (e.g. Prince2 Agile) or as a meaningless marketing buzzword with nothing behind it (‘We bring agile to your company’)
• Agile as a bad excuse for the chaos
• Perception of Agile as a liberation movement or an opposite view. This leads to a lot of unnecessary polarisation and dogmatic fights which method is right

So there is obviously quite some rubbish going on and all this is very much linked to insufficient knowledge about specific agile methodologies and their goals, resulting in typical misconceptions. Well – reason enough to come up with my personal ‘top 10 list’!

Misconception 1: Agile is better (or worse) than Waterfall

How it works in reality: Every situation requires its own, adopted approach. So, no reason to get dogmatic and start believing that there is a “solution for everything”, right? Waterfall is suitable if you act in a predictable environment, where requirements are clear and stable from the beginning and if there is not much feedback & adaption needed on the way – also in terms on how you achieve the expected result. A typical waterfall scenario would therefore be:  Build additional 3 floors on top of a building. If this is not the case, I would prefer an agile approach. The interesting question to ask here is: In which environment do you act? Up to you to answer.

Misconception 2: Agile means no planning

How it works in reality: Planning is very crucial in agile projects, but there is less upfront planning and agile generally does it differently than in the traditional waterfall approach. Planning is not done one time (following build, deploy, run phases), but continuously (e.g. every 7 days), usually in a very structured manner and having the long-term vision in mind. The more underlying information you have, the better you can refine your original plans. This is heavily dependent on early feedback. Fail often, but fail early. So initial requirements, prioritizations, estimates and time plans are constantly refined based on feedback. Again this is especially successful in certain environments (see my previous point).

Misconception 3: Agile needs governance on top to make sure it’s aligned to company vision

How it works in reality: Mature agile frameworks like Scrum are truly top-down, from the beginning to the end: Starting from the vision (backed by a business case), Epics and User Stories are iteratively developed, and iteratively implemented in sprints. If you do it right, you include operational service requirements into user stories. The agile mechanism can be applied on Project level, but also on Program, Portfolio and Enterprise level. A continuos “evaluate – direct – monitor” is applied, the ‘how’ usually follows the principle of self-organization. If you work in a regulated environment and have to demonstrate corporate IT governance for agile projects, have a look at this excellent presentation. Agile also proves to be very effective for large projects, the ‘Scaled Agile Framework’ or ‘Scrum of Scrums’ give you some good ideas on that.

Misconception 4: Agile is for Software Development

How it works in reality: Agile methods are a specific way to deliver results. Altough they were first used by the software developer community in the 90ies, agile per se has nothing to do with SW Development. There are many examples around where agile is increasingly used outside SW and even outside IT, ranging from Finance, Marketing&Sales to Product Development.

Misconception 5: Agile only makes sense in ‘High-Speed IT’

How it works in reality: The concept of bimodal IT (or two-speed IT), which was brought up by Gartner, pretends that the world of agile is the world of speed. I think this is quite misleading. Agile mainly promotes the mechanism of early and continuos feedback. This way, agile methodologies can help you to do the right things the right way very early in a project lifecycle, hence delivering faster. So agile itself has nothing ‘speedy’, but in can result in faster time to market. The point is also, that agile makes absolutely sense in ‘slow IT’. For example, if the customer hasn’t clear requirements from the beginning (which in my experience is pretty common), agile can help to iteratively develop the requirements, a basic idea we already know from prototyping.

Misconception 6: Agile means less discipline

How it works in reality:  Yes, Agile promotes self-organization. This often leads to the misconception that work in an agile project is chaotic. The opposite is true. Mature agile methods like Scrum require a high level of discipline by outlining a clear process and set of rules to be followed. However, within these roles agile promotes the principle of self-organization. For example, it’s up to the team, how they achieve the sprint result.

Misconception 7: “Agile means no documentation”

How it works in reality: Applying agile means at the end often more documentation. In agile projects, you start delivering early and from a planning perspective you start with the information you have. At the beginning things are not accurate by nature. So there is little upfront documentation, it’s rather ‘as required’. During agile projects, there are short cycles of feedback and sprints, in which plans and requirements are continuously challenged and refined. This results in continuous extension and adaption of documentation. On top, it requires a very strong Change Control.

Misconception 8: Agile is a Project Management approach

How it works in reality: Agile as a Projetct Management framework? Yes and no. Taking again the example of Scrum, the most popular method, you can use it in 3 different ways:

• Explicitly as a Project Management Framework (with closed backlog and with a defined project end, that defines a ‘project’)
• Without predefined end and with open product backlog (towards a vision) – Similar to CSI in ITIL
• Or you just take a piece out of it – for example the Scrumboard – and use it to organize the daily work in teams (whatever kind work this is, it doesn’t matter). However, this is not anymore what agile is at it’s core, but the so-called ‘Scrumbutt’ can sometimes help, too.

Misconception 9: Agile means more flexibility, but less stability

How it works in reality: In daily live, we have to manage trade-offs. One of them is the trade-off between flexibility and stability. Achieving more flexibility usually means less stability and vice-versa, the question is which balance is right for your environment. Although agile usually goes more into direction of flexibility, it’s often forgotten that the most acknowledged definition of agile from Highsmith (2002) states that agile ‘is the ability to balance stability and flexibility’. Agile methods reach this balance between stability and flexibility on a high level and you can see that very well in Scrum, where the product backlog is open for changes by the product owner at any time, but the sprint itself is protected.

Misconception 10: Agile is for the nerds (The Ops view)

How it works in reality: Well, ‘They’ think the same about ‘Us’ (->the Dev view). But luckily DevOps is coming soon, so finally there is no more ‘Them’ and ‘Us’, just a common goal towards the customer with common incentives 😉