7 Agile Myths


Minuten Lesezeit

Sei dabei und sichere Dir bis zum 31.05.2024 Dein Early-Bird Ticket!

Juni 14, 2012

Hol Dir hier das kostenlose Probekapitel meines Buchs

Klicke einfach auf den folgenden Link und melde Dich an.

Today I had a lightning talk at the ACE!Conference in Krakow (as you probably know, I’m a lightning talk addict ;)) and talked about seven Agile Myths. You’ll hear about these myths most of the time on management level, but some of them can be found on the development level, too. IMHO it’s important to be aware of these myths to be prepared for possible discussions.

Agile = No documentation

This is one of the most famous myths and I think we have to blame the agile manifesto for this. The line „Working software over comprehensive documentation“ is often misunderstood with no documentation at all. But how could agile Frameworks like Scrum survive in highly regulated environments like the medical or financial industry if this would be right. For sure there is documentation, but we don’t waste time on documents that deliver no value to the project.

Agile = Anarchy

The biggest fear of any manager is to lose control over their agile teams, because they think self organisation is the same as anarchy. Yes, the role of management changes but they still play an important role in their company. They are needed to define clear visions and goals and the constraints of a project. Only within these „fences“ the team can work self organized. They are also needed to help the team to gain their full potential. This has nothing to do with anarchy.

Agile = faster

IMHO it was a bad idea to name an iteration in Scrum a sprint. This implies that everything is real fast in agile. But at least in the beginning the complete opposite is true. Building in quality into a product takes time and quality is not discussable. You’ll be able to harvest the fruits later as you’ll have less bugs and the software is more maintainable and that’s the point where agile is bringing you up to speed.

Agile = silver bullet

Yes, this true. Just kidding 😉 There is no silver bullet in software development. I repeat: There is no silver bullet in software development. Sure, the process of software development has some impact, but in the end it is all about the people in a team. I saw awesome products created by a „waterfall team“ and crappy software by agile teams. In the end it is all about the right people at the right place or as written in the agile manifest: Individuals and interactions over processes and tools (this also applies to Scrum, Kanban, XP and any other process).

Agile = simple switch

Simple said: No it isn’t. The frameworks itself can be explained within 10 minutes, but what is often forgotten are the needed mindset behind and the principles that agile methods are based upon (Lean Thinking, Pull vs. Push, empiric process control, iterations and increments, self organisation…). In bigger corporations it may take years until you can talk about an agile company. You won’t believe it, but it is not enough to send your team to a two days ScrumMaster training…

Agile = Easy

How can it be easy to deliver a possible shippable product every 1 – 4 weeks? In the past you weren’t able to do it after one year. It is a lot of hard work to get there and it is for sure not an easy thing to do. And I don’t want to mention continuous deployment here…

Agile = software development

Often the agile journey starts in software development, but it should not stop here. To have an agile software development team in an non-agile environment is like planting a tree in the desert –> it won’t survive. The whole company culture has to change, everybody needs to adhere to the agile principles like lean thinking. Otherwise your agile transition will end in a blind alley and a lot of frustration.

What agile myths do you know. What are your experience with those myths? I’m looking forward to your comments!

BTW, here are the corresponding slides of the talk:

And here is the corresponding video of the lightning talk:

Lightning Talk from ACE! Conferences on Vimeo.

About the author 

Marc Löffler

Marc Löffler ist Keynote-Speaker, Autor und Mentor für passionierte Scrum Master. Er befasst sich schon seit 2005 leidenschaftlich mit agilen Methoden, wie z.B. Scrum, Kanban oder eXtreme Programming. Bevor er mit dem Thema Agilität in Berührung gekommen war, hat er als zertifizierter Projektmanager (IPMA) bei Firmen wie Volkswagen, Siemens und EADS erfolgreich multinationale Projekte geleitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und genau die Form von Agilität zu finden, die zum jeweiligen Unternehmen passt. Dabei nutzt er sein PASSION Modell, um die jeweilige Situation zu analysieren und sinnvolle nächste Schritte hin zur passionierten, agilen Organisation zu definieren. Er liebt es, neue Einsichten zu generieren, und unterstützt Unternehmen dabei, Probleme aus kreativen, neuen Blickwinkeln zu betrachten. Seit September 2018 ist er zertifizierter Professional Speaker GSA (SHB) mit der besten Keynote seines Jahrgangs. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag. Im Jahr 2018 folgte das Buch „Improving Agile Retrospectives“ bei Addison Wesley. Im Februar 2022 folgte dann das Buch "Die Scrum Master Journey" beim BusinessVillage Verlag.

Leave a Reply

Your email address will not be published. Required fields are marked

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

      1. Indeed a myth! Manager have to create the environment and conditions for agile teams. This is were many agile introductions fail. Managent should focus upon both organizational and people aspects of agile. A model that can be used for this is the People CMM (which is a supporting model from the CMMI). I’ve witten some though on how to help management to implement agile. And I also see a useful role for project managers in agile organizations.

  1. Hello Marc: I generally agree with all of the myths and I would certainly include an honorable mention for the No Manager role. This role does need to adapt, as do many of the hands off roles in larger organizations (including Project Managers, Technical Manager, Conceptual Architects, etc.)

    As to Agile is Faster. The terminology needs to be refined. All of my teams deliver in the first sprint. If they are not delivering then they are below my personal standards. Now, what are they delivering: Naturally a piece of value that can either be delivered to production or demonstrable in a way that our business partners can say „great keep going“ or „not good, cancel the project“. Of course, there’s a middle ground but your audience needs to understand this.

    As to Agile = Software development. Absolutely correct! Agile applies to the entire organization but enabling that to occur is a big undertaking which a traditional organizations avoid. The biggest reason is that it’s a large undertaking, the process owners are often those who need to move on or have transferable skills and sadly, the Development CTOs/VP/Directors often sell agile an a development methodology in order to build their own empire. (Seen it many times.)

    However, that’s not the point I really want to make. Being pedantic, I would ask you to change your comparison of trees growing in the desert because there are many different types of trees that indeed thrive in parched, arid areas; namely deserts.

    All good stuff.


    1. Hi David

      Thanks for your comment! I’m currently working on refining my myths. Do you have a better metaphor for the tree in the desert? Maybe placing a human in the desert?


{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hol Dir die kostenlose Anleitung für
Deine persönliche