Agile is not Magic!

When you search google images for agile you will mostly get a plethora of marketing related pages selling you consulting services and certifications in all “agile” methodologies and frameworks known to man. Beginners might be overwhelmed with the amount of information and might not now where to start their agile journey.

So let’s ask ourselves, what is agile? According to Google agile is something that is “able to move quickly and easily”, like a cat or a feline that can move swiftly, silently from place to place always alert and adapting against new threats. So in order to understand the term, what would be the opposite kind of animal, some animal not agile? maybe an elephant?

Therefore, if we we are comparing software development to the act of crossing the forest, obviously a feline would go faster, but imagine there was a big river, then the elephant would be better equipped to deal with it and the poor feline might drown.

This is the clear example of a classic Agile vs Waterfall comparison. Even tough agile might be preferred nowadays, there are still some use cases where waterfall would be still valid. However, my point is not about which one is better, but why it is so easy to understand waterfall but it seems that agile is more of an abstract concept that has evolved into just a commercial/generic term.

Recruiters everywhere requests candidates to have zillions of years of experience with “agile”, “scrum”, “kanban”, “devops”, some companies have started launching expensive training and workshops with every agile keyword in their titles, something like “Lean Master Agile Kanban Coach”, managers love to use agile as an excuse for overworking and disorganization, developers use it as a way to avoid writing documentation, if you are agile you don’t need to document, you only need to talk with everyone and keep the backlog in your head right? seems like magic.

Unfortunately things are not that easy in the real world, agile has become a commercial thing and is sold as the panacea to soothe all our software development aches, and the main problem is that most people do not even realize where agile even comes from.

In order to understand agile we have to come back to the origins, forget about Scrum, Kanban, SAFE and so on, let’s go back to basics, in 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss these lightweight development methods, including among others Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin.

Together they published the Manifesto for Agile Software Development as a way to help software development teams develop code more efficiently:

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

Which is based on twelve principles:

• Customer satisfaction by early and continuous delivery of valuable software.
• Welcome changing requirements, even in late development.
• Deliver working software frequently (weeks rather than months)
• Close, daily cooperation between business people and developers
• Projects are built around motivated individuals, who should be trusted
• Face-to-face conversation is the best form of communication (co-location)
• Working software is the primary measure of progress
• Sustainable development, able to maintain a constant pace
• Continuous attention to technical excellence and good design
• Simplicity—the art of maximizing the amount of work not done—is essential
• Best architectures, requirements, and designs emerge from self-organizing teams
• Regularly, the team reflects on how to become more effective, and adjusts accordingly

Therefore, Agile Software Development, is focused on interactions, customer collaboration, working software and responding to change and it explicitly states that while there is value in the items on the right, we value the items on the left more.

This small phrase has been misunderstood, and has lead to many people to only focus on the items on the left, disregarding process, tools, documentation, and planning, which in the real enterprise world is very irresponsible and not even possible (heard about something called compliance? security? yeah right).

So let me answer it for you with some examples:

• We can interact everyday with each other but also we need to be efficient, you can’t expect to interact efficiently if you keep a list of tasks in your head and have to explain all over again everything, it would be way better to have it in written form so it is easier to share (ever heard of a backlog?). Furthermore, even though we could write our backlog in PostIts or napkins, using the right tool will save us time and money and will enable us to collaborate better.
• We can develop excellent working software, but the moment your freelance developer is leaving your company and you have to support the application he has developed and you found out he is agile and therefore generated no documentation, you are putting yourself and your company at risk.
• We can collaborate with the client and embrace change, but if the client changes his mind every five minutes and this changes are not at least written down, discussed and analysed to try to get a consensus and move towards a common vision, then no matter how many sprints you will perform, nothing of value will be produced.
• We can respond to change, but also we can make a high level plan that can help our development efforts, deadlines are something real, and in the real world projects you cannot push the deadline indefinitely.

Agile most of all is a mindset, and agile should also be enterprise aware and adapted to the context, while keeping the main principles of quality, simplicity and customer satisfaction.

That’s why Agile is not Magic, it takes discipline and effort.