A developers review and small changes to the 12 principles of agile.

Feel free to disagree with my opinions in the comments.

Simplicity

Simplicity--the art of maximizing the amount of work not done--is essential.

It is a little hard to determine exactly what the authors were trying to say for this one. So, I am going to be making an assumption here that may or may not be correct.

With that said, I believe, the intent with this principle is to suggest that it is very important to create a simple product. And, that the best way to do so is to do as little work as possible.

Revised

No changes

I agree very much with this principle and have no changes I can make that would add any increased value.

However, I did assume the authors of the original were referring only to the final product. So, although I would not change the wording of the principle I do want to change how it is interpreted. Instead of restricting the simplicity to only our user-facing product I would like to extend this principle to the entire workflow.

Before I go into why and what it means, I do want to mention that this could be what the original authors intended.

Now, I think it is much easier to discuss simplicity by instead considering the opposite, complexity. That is, to be more simple is the same as being less complex. Additionally, I would like to split complexity between tasks that are difficult and those that are simply time-consuming.

Therefore, in order for something to be simple it is either not difficult or not time-consuming ( small caveat that time-consuming is based on active work and not waiting for a download to finish, looking at you npm install ) or both of course.

The reason I bring this all up is that I believe tools and patterns such as continuous integration and DevOps inherently make your developer workflow more complex and thus less simple. On the other hand, it saves so much time and effort that it outweighs the complexity.

Self-Organizing

The best architectures, requirements, and designs emerge from self-organizing teams.

This is, in my opinion, the most impactful principle. It is deceptively simple at first glance but has so many benefits that I could write an entire series about it alone.

Briefly, this states that self-organizing teams build the best stuff. In fact, as far as I understand, all the agile derivatives like Scrum and SAFe include this in their own rules.

Instead of going into all the reasons why self-organizing teams are so important I just want you to imagine your favorite sports game where no one on the team liked each other and they were all specialists in the same position. Like, if a football team ran 11 quarterbacks on offense.

Revised

The best products emerge from self-organizing teams.

I simply made it more generic and inclusive. Other than that, I think this is still the most important principle.

In fact, I would argue that if your company is unable to adopt this principle to some degree you will find the rest of the principles much more difficult, if not impossible.

Reflections

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Besides just holding these discussions it is essential that the team can do two things.

1. Be able to give honest constructive feedback on each other
2. Be able to adapt their own work style and flow based on this feedback

Fostering a culture and team capable of these two things can be difficult to say the least.

If you are familiar with Scrum these are the retrospective meetings that are meant to occur at the end of each Sprint.

I would like to mention that the principle does not specify a meeting, but that meetings can be assumed as the default method to discuss given an earlier principle.

Revised

As a team continuously reflect on how to become more effective, then tune and adjust accordingly.

My only complaint on this one is the regular intervals clause. It may be that the best method for your team is in fact a regularly recurring meeting but an as needed team lunch could also work.

Plus this could reduce your meeting count which feels good.

I would also add that in some cases you may not need to conduct a full team meeting and instead just include a few members that are most relevant to the issue.

Besides that, team engagement is critical to this being effective. I have also noticed a trend that those who dislike agile tend to skip, not participant or in some cases remove this entirely from their workflow. If enough people stop participating it can then evolve to this meeting being removed from the calendar completely.

Without this reflection a team will consistently repeat the same mistakes over and over again. In most cases resulting in employee churn and burn out.

That is all for the fourth chapter. Thank you for reading.