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.
here are some more:
http://imistaken.blogspot.co.il/2012/06/more-agile-myths.html
Hi Lior
Thanks for the link. The myths you listed are unfortunately also quite common.
– marc
Agile = No role for Manager
Thanks, this is one I have to add to my list 🙂
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.
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.
-d
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?
Cheers
Marc