Learning Agile (Book Review): You would be surprised who wrote this.

I actually can't believe that I didn’t know who created the Agile manifesto (The same guys that authored Clean Architecture, DDIA, and other books that I've been reading are the ones responsible for this).

To review my raw notes (they are ugly) here they are exported from my Kindle: Learning Agile: Understanding Scrum, XP, Lean, and Kanban Raw Notes

And as a quick preference before I continue, I skipped over the Product Owner part of the book since I am an engineer trying to understand how I can ship better, faster, clean, and on-time code. So, I won’t bother to read how to create burn-down charts.

Just the pure execution mentality and how to make the company actually work.

The Core Idea

The whole thing with Agile is that people (managers, and product managers) implement Agile without knowing why they are implementing it. Meaning that they just add meetings and ceremonies without even thinking about it.

The whole goal of Agile is to have a methodology and more importantly a mentality where developers, designers, and stakeholders (business or even clients) have proactive communication so WE DON’T waste time building the wrong thing or creating something that nobody wants.

To be more specific, here are the core principles:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

*That is, while there is value in the items on the right, we value the items on the left more.

As Engineers, we are able to get time back

Honestly, throughout the book as a developer, I was really critical about the whole Agile ceremonies but the moment you understand that the core principle is that you are able to influence the product faster, and your ideas can be heard before they explode in the product, you start to understand the value of this.

Values individuals and interactions over processes and tools

The idea is that we are also able to pull in things that we think are required for the product to be shipped. We minimize downtime in miscellaneous tasks and try to create a queue of tasks that we are able to work on one task at a time.

Clean Architecture is able to speed up development if it's done with Agile Practices and specifically if you are able to break down ad-hoc things.

The old way of engineering where we spent weeks doing system design work is flawed. I am not saying we should not do a high-level design doc but we should understand that a design doc is something that SHOULD evolve, instead, we could start by defining a minimal marketable product where you start the product creation with a clean MVP idea and start the high-level design in parallel.

Personal Thought

I think any team can implement Agile and fail or succeed in a mediocre way, BUT I have seen good teams working with Agile and being able to ship the best product to the end consumer.

If you want to create the BEST product for the end consumer, you should EDUCATE not only the client but also stakeholders, developers, business people, and managers on how your team works and they have to see value from it. My current job is in SECURITY, my last job was in PRIVACY. Privacy is harder because of the US Constitution there are monetary consequences on failure. Meaning that each data record could lead to a $200 fine from the US Government. Nevertheless, we shipped faster than my current job but that does not mean that the product is better or worse.

This means that I can confidently say that if I were to take the BEST out of both my professional experiences both places would be able to ship high quality, fast, reliable, and GOOD software but engineers and stakeholders of the product need to understand Agile and Clean Architecture.