Agile Zone is brought to you in partnership with:

Marc Löffler works as an Agile Coach with Sybit GmbH. Before getting in touch with agile methods and principles in 2006 he was working as a traditional project manager for companies like Volkswagen AG or Siemens AG. His passion is to help teams that are struggling with agile transitions and overcoming dysfunctional behaviour. He loves to generate new insights by approaching common problems from the other side and trying to deliberately make havoc of the process. Marc is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

7 Agile Myths

  • submit to reddit

Last year 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:

Lightning Talk from ACE! Conferences on Vimeo.

Published at DZone with permission of Marc Löffler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Martin Feuchtwanger replied on Tue, 2013/02/05 - 12:16pm

Agile = Scrum, Kanban, XP or any other Process

That's a big myth that many consultants like to perpetuate.

Diego Zanella replied on Wed, 2013/02/06 - 8:49am

The greatest myth of Agile is that Clients welcome it, and, even more, that they understand it. It's time to realise that the whole idea of "embracing changes", to the Client, means "I can change my mind as often as I like, and get everything I ask for, complete and functional".

You can explain them Agile methodologies as much as you like, but Clients will still hold you responsible if they don't get everything they asked, including the hundred changes they made half way through the project, and the fact that you said "yes", embracing change, will make things worse.

Always remember the golden rule: when a Client says "I would like X instead of Y", he means "I want X in addition to Y". Saying "no" is, more often than not, the best thing to do.

Florin Jurcovici replied on Wed, 2013/02/06 - 3:00pm in response to: Diego Zanella

Here's an idea: instead of telling your customers that you are agile and embrace change, tell them these simple rules:

Only chicken

  • add stories to the product backlog
  • reorder stories in the product backlog, but only between sprints
  • read the scrum dashboard

Only pigs

  • add stories to a sprint
  • update the sprint dashboard
  • speak in stand-up meetings
  • score stories in the product backlog

And also tell them that while the above rules are carved in stone, it's OK to talk to developers directly whenever needed, and forward them to developers whenever they start to talk about requirements to someone not part of the development team.

If they listen and agree, you might get to a working process, after a bit of training them on it. After seeing results, the customer may start to actually like it.

Agile methods have very much to do with discipline. Customers, since they don't understand software development, are notoriously indisciplined. If you want to work agile with a customer, it's you who has to enforce this discipline.

Diego Zanella replied on Wed, 2013/02/06 - 3:07pm in response to: Florin Jurcovici

Unfortunately, I still have to find a Customer who cares about development process. You can explain rules as much as you like, they won't observe them. They might say that they agree with them, but, invariably, they will conveniently "forget" them at the first occasion.

Chickens, pigs, sprint, stand-up meetings, they are all buzzwords and nothing else. The only level of involvement they would accept is the "I'm the one who pays. I tell you what to do, you do it".

For the record, I experienced the same behaviour in managers, "upper managers" and even department directors. They don't really want to be involved, they just want to get the Customers off their back, as soon as possible.

Florin Jurcovici replied on Wed, 2013/02/06 - 5:15pm in response to: Diego Zanella

Of course customers and bosses always want. What they get is a different story.

I learned this the hard way, in a very short period of time. In the distant past, it happened, on a project, that the customer asked for a deadline he most definitely wouldn't get. But pressure from my boss made me promise that we will stick to that deadline. Of course we didn't, and the customer was not pleased - not pleased at all, and all the anger was taken out on me. So I learned my lesson. Next time when the situation tended to repeat itself, I bluntly said it's impossible. No matter what was argued about, I kept saying it's impossible. After both the boss and the customer got tired (I wasn't in a position to be fired, because they needed me to do the job, and a replacement on short notice was impossible), they finally asked the reasonable question: when will it be ready? I gave a realistic and doable deadline, and stuck to it - the delivery was on time. I never had to live through the same situation again, at that job. The boss had learned his lesson, and did a good job afterwards in passing it on to new customers.

Diego Zanella replied on Wed, 2013/02/06 - 6:16pm in response to: Florin Jurcovici

Thank for sharing your experience, Florin. That confirms that, often, it's important to be able to say "no" to Customers and managers. In fact, I learned that lesson over a decade ago, and I rarely have to deal with absurd deadlines set by someone else.

A Johny replied on Fri, 2013/02/08 - 7:49am

I don't understand this: Agile = silver bullet. What have agile in common with tampon??? Excuse my bad understanding of English.

Alan Felice replied on Fri, 2013/02/08 - 8:41am in response to: Florin Jurcovici

I'm currently trying to go one step further (and yes, I learned it the hard way, too): never give time estimations for things you don't reasonably know (from previous experiences) or that are not reasonable clear. No matter what was argued about, I keep saying "I don't know when".

The only thing it's reasonable for me, in such situation, is: "Give me x-y work days to further investigate, maybe than I will be able to tell you something different."

Martin Feuchtwanger replied on Fri, 2013/02/08 - 2:54pm in response to: A Johny

I don't know the origin, but i think "silver bullet" means panacea or "magic technology".

Florin Jurcovici replied on Sat, 2013/02/09 - 4:15am in response to: Alan Felice

You might want to read this:

It'll introduce you to the concept of the cone of uncertainty, which is very helpful. Plus it provides several statistically won insights into what takes how much, how to compute an optimal project duration and team size, for example. I find it really useful.

bill selig replied on Mon, 2013/02/11 - 2:04pm

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.