Ultimate Agile Mythbusting Guide
Commonly repeated agile mistakes and misconceptions
Have you ever met those suit & tie guys saying “Yeah, at our company we do Agile!” and then you realised what they are doing is far from what anyone sane would call agile? Or maybe you are the new guy in the game who is afraid of asking questions about agile?
No worries anymore. Our Ultimate Mythbusting Guide is aimed to resolve doubts about agile is and correct the mistakes in implementing it.
So here it goes - the list of most (in)famous agile myths that our team members encountered in their careers.
1. There is no documentation in Agile
This myth comes mostly from the misinterpretation of the classic 2001 Agile manifesto. The document indeed says that it’s authors value “working software over comprehensive documentation.” However, they do not say that documentation should necessarily be skipped. As the note in the end highlights: “while there is value in the items on the right [documentation], we value the items on the left [working software] more.”
What does it mean for companies pursuing agile?
Create documentation in a more useful form, but NOT abandoning documentation at all. Effort spent on documentation should be proportional to its value. The rule of thumb is: if no one is going to read it after it’s written down, don’t write it down.
For example, instead of writing down all the ideas in a scientific form, take out the phone from your pocket and shoot some photos of the things your team have previously written down on a whiteboard in terms of the current project. Yes, this can also be a form of your agile documentation!
2. Agile is only for software developers
BEEP. Wrong answer!
The correct one is: agile can be used in companies from really different backgrounds, and only in some very specific cases it may not be an applicable choice.
Just look at the 12 Principles of agile. Although a word “software” appears there a few times, you can usually easily replace it with another word: “product”, and it will still make sense. Like in this part:
3. Agile is hard to understand
It is not. The basic principles of agile may be enough to point you into the right direction. You probably don’t need to read hundred of books and articles on agile to decide if this is a thing you would like to implement in your team.
However, as it is usually with many other ideas and methods, you have to keep one thing in mind…
4. You can implement agile in no time
BEEP. Wrong again!
Agile is easy to understand, but hard to master. That’s cause you can’t just come to your company in the morning and tell your team - instead of your standard “Mornin’!” - “we’re gonna be Agile from now on!”
If you try it that way - you will probably fail. Very fast and very painfully.
Implementing agile requires a team that has a knowledge about your organization and is dedicated to its mission. Some of your coworkers may not be happy about transitioning to agile in the first place, so educating them properly is incredibly important.
5. Agile will solve all your organisational problems
No, it won’t. Agile is a great thing to enhance the effectiveness of your team and even the whole organisation, but if there are some deeper issues, changing how you manage your work may not be enough.
Because of this, you should not think of agile as a medicine to cure all your problems. It’s more of a great vitamin supplement, which won’t make you feel much better as long as your overall diet and lifestyle suck.
6. Agile requires no planning
This myth is partially linked to the one claiming there is no documentation in Agile. The issue comes, once again, mostly from the misinterpretation of Agile manifesto and the 12 principles.
In fact, agile work does require planning, but in a bit different form to the planning happening in a waterfall approach. As agile implies constant focus on the feedback provided by customers, the plan here focuses on short- rather than long-term tasks. There still has to be, however, a main vision for what you’re building, which focuses on the big picture.
7. Agile == Scrum
No, these are not the same things. Scrum is only one of many frameworks that take the agile principles and turn them in a more codified set of rules. When you hear about company doing stand-ups or retrospectives, it probably means they are doing agile in a Scrum way.
However, it is also important to highlight at this point, that it’s best to combine different ideas than stick to a specific textbook or manual. Lean management, Kanban, Scrum, Test Driven Development, etc. - after getting some hands-on experience with all of these different methods, you will probably realise they can be mixed and combined into a system specific to your company or team.
In the end, it’s all about figuring a method that fits best you and your teammates, isn’t it?