Is Agile development really that great

ADM: Why are some developers opposed to Agile if it’s supposed to be so great?

Olson: Change is hard, so regardless of whether something is better, it’s still a different way of working.  I think this is the primary reason why some developers oppose agile.  Change like this is often accompanied by FUD (fear, uncertainty, and doubt).

ADM: How does Agile deliver quality product when it seems as if you spend less time on big features?

Olson: There’s nothing in Agile that says you spend more or less time on features.  Many Agile organizations try to break large pieces of work into smaller pieces.  This allows teams to release sooner and accelerate their learning.  This acceleration of learning will help to build higher quality software.

ADM: Does Agile eliminate or reduce inefficiencies in the development cycle?

Olson: Teams can be inefficient using any process. One of the most important aspects of agile organizations is the ability to inspect and adapt. Agile teams have regular retrospectives to improve their process. Inefficiencies tend to get highlighted and adjustments regularly occur to remedy them.

ADM: Can Agile methods translate to teams other than engineering?

Olson: Yes! I’ve seen Agile work great in marketing, sales, and recruiting teams.

ADM: Doesn’t Agile mean you can change your mind all the time? How does anything get “finished”?

Olson: This is a common misconception. Agile means that organizations can embrace change – it doesn’t mean chaos. Agile teams often have a strict “definition of done” for work, so it’s unambiguous when things are finished.

ADM: How can you keep the team focused on the big picture if their work is broken up into smaller pieces?

Olson: This is usually the responsibility of the product owner (or product manager). I’ve seen teams use the 5 levels of Agile planning to help connect work to a higher vision.

ADM: Are there times when the waterfall method is really a better option?

Olson: That’s not my expertise. I’ve heard arguments around using a “waterfall-like” process for larger projects with heavy compliance requirements (like building a plane or something).

ADM: Do the details get lost in an agile process because you stop documenting everything? How do you keep track of everything?

Olson: What??? Who says you don’t document things in Agile? There are user stories that are written down or stored within an Agile project management system. Earlier in my career, I worked on one of these which is very good at keeping track of everything. At Pendo, we use a physical board where everything is managed.

Agile simply doesn’t recommend documenting things solely for the sake of documenting them.

ADM: Aren’t you opening up the team to more criticism and frustration by inviting continual feedback? They won’t feel a sense of completion.

Olson: One of the core tenets of Agile is to promote trust and safety on the team. Criticism from customers is criticism of the work – not criticism of the team.  The team wants to deliver software that delivers value to customers. Feedback is how the team steers towards successful completion and is honestly a gift.

ADM: Does Agile mean developers can work faster? Are features easier to complete?

Olson: Agile isn’t magic pixie dust that makes work easier and happen faster – wouldn’t that be nice!  Sometimes it helps to break work into pieces because you may learn that you don’t need to build everything you thought you needed to build when you planned the work.

ADM: How do you see Agile development differing between small startups, and large corporations?

Olson: Scaling Agile in large organizations brings a new set of challenges. The Agile community has  developed a lot of newer practices to help address these new challenges like the Scaled Agile Framework (SAFe).