More Agile Myths

Marc Löffler in this post talks about some agile Myths. about a year ago I blogged about some agile misconceptions. Here are some to add to this list.

Agile = No Design

In an agile process you usually wont see a specific design phase. In fact scrum for example does not explicitly talk about design at all. This leads some people to think that in an agile process design is not done or is not deemed important. Well actually quite the opposite. Design is such an important part of software development that trying to box it into a specific time/phase in a process simply doesn’t work. When development software you need the flexibility to change/update/adopt your design as you learn more and more.that is why in agile circles we will usually talk about emergent design, or iterative design. the idea is to design more and more of the product as we learn more and more about the problem.

Agile = No Planning

It still puzzles me how people reaches this conclusion. Yes there is no one single long term plan that we follow. But just by looking one can clearly see that most of the structure you have when following an agile process is centered around planning. In scrum in all the ceremonies we do some sort of planning. In sprint planning its quite obvious we plan a sprint, in daily meeting we pan the next day, in demo we gather feedback in order to help plan the next sprint and in a retrospect we plan how to improve.

Agile = Small Teams

When I started out most of the time coming to large companies I heard them saying that while agile sounded nice it seems to be only appropriate for small teams mainly or those “crazy websites” projects. Funny enough I’m lately starting to hear (usually in small companies) that while agile is nice, its too much of a process and is too strict for what we need. its only good for bigger projects when you need a process to get going. It’s funny how the wheel turns.
In truth an agile process can be used in both situation, and the actual goal of the process is to find a balance after some trial an error of course. on one hand we want to give enough structure as to avoid complete chaos and on the other to still allow for the flexibility and agility which are so important to stay competitive in the software industry.

What other agile myths do you know? What is your experience with those myths? feel free to comment…

Want to adopt Agile and don’t know where to start?
click here to learn

Posted in: Agile Principles,Design,Planning