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

Part 1: Priority, Requirements, and Delivery

Feel free to disagree with my opinions in the comments.

Business People

Business people and developers must work
together daily throughout the project.

Starting off with an easy one. Basically, instead of having two separate groups of people one focused on the business and another on development. Agile advises on having these two work together daily to create the best product.

Revised

Business people and developers must work
together throughout the project.

Only a small change on this one, simply remove the daily part.

From all my experiences daily interaction with business, sales, marketing, or any other group increases the project churn rate. The reason being, these people do not just look at your progress and say good job keep it up, they almost always want to chime in on a "small" but important idea.

Once or twice this doesn't affect much but daily can hinder progress dramatically in the overall direction of the product.
You might say this goes against accepting change, but ideas from your boss are typically weighted much higher than any other even if the idea is much less valuable.

So accept feedback, but weigh the ideas against each other for what they are and not who proposed them. Or in other words, don't slow down your team's momentum because your CEO thought your color choices were "so last year".

Motivation

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

This principle has a little more going on but is not too hard.

First, people who are motivated build better products and usually faster.
So, you should build a team around people who are motivated for the highest quality product.

Second, create an environment that allows these motivated developers to get work done. You may need to support them from time to time as well.
It is not explicitly stated but I am going to say they mean things like training, advice, purchasing things, but really anything your team members need.

Finally, trust your team. You hire a team of experts, you do not need to micromanage them. You are only going to create a worse product, in a longer amount of time with more developers quitting.

Revised

Build projects around talented individuals.
Give them the environment and support they need,
and trust them to get the job done.

My only change was simply changing motivated to talented.
This may seem like a strange change given how I agreed with the original statement above.

The reason is, being motivated does not mean you are good at your job.
I know plenty of motivated people who do not contribute as much as they would like, and in some cases, their motivation actually hurts the rest of the team.

Instead, I would prefer talented individuals who are experts in their field or fields. Then, by giving them a proper environment, support and trust you will naturally motivate them.

Conveyance

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

The last one of the day is going to potentially be a bit more debatable.
It simply says the best way to communicate to developers is in-person.

Now I think in-person communication is definitely preferred in a lot of cases, however, I will explain why I think alternatives have more benefits.

Small aside, whenever conveyance is brought up I rewatch Sequelitis of Megaman X by Egoraptor, as a previous game developer this comes up quite frequently.

Revised

Use the most efficient method of communication depending on what you are going to be communicating. With a preference for asynchronous methods to reduce
context switching.

My first change is to simply say to use the best method for what you are trying to communicate. As new forms of communication are used for development less and less will require in-person meetings or one on one chats. There is no reason to walk over to my desk just to tell me your pull request is ready to review, I will get an automated email or a slack message.

The biggest change is a recommendation on asynchronous methods, this would be things like emails, pull request comments, and issue tracker comments. These are things that are sent to me and I can respond at my most convenient time. Whereas synchronous methods are real-time such as in-person, real-time chat such as slack or voice tools like Skype or Webex.

This follows my general pattern of giving as much time to developers as possible to work without distractions. Asynchronous methods allow developers to work without having to respond to pings, open office chats or ad-hoc meetings. This extra time lets developers work better and stay in that focus mode longer. ( I don't generally fall into the whole focus mode belief but working uninterrupted for 4 hours is simply not comparable to being interrupted every 15 minutes. )

Most importantly, everyone on the team should follow the same guidelines. It gets a bit confusing to have half the team send emails and the other using issue tracker comments as the method of discussing future ideas.

Especially making sure managers and business people follow the same guidelines. Having zero in-person meetings for developers but then every meeting involving a manager happens in-person in a conference room will not only be confusing but
will increase the number of tools used and add just that much more friction for the team.

In fact, if it wasn't too specific I would add "no ad-hoc meetings allowed" or better yet "no meetings" at all. Where I define a meeting as two or more people who talk in real-time, either in-person or online, with a specific agenda. This does not count pairs who are working on a task together over voice or in-person.

However, I do believe there are a small number of use cases for meetings that when agreed upon and time-boxed can be very effective. Jumping into meetings as the default all the time, to me, is asking for trouble.

Going to end my meeting rant here, I may discuss it again in the future.

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